plugins/tea-sdlc
2
0
Fork 0
Code Issues 3 Pull Requests Actions Releases Activity
111 Commits 1 Branch 0 Tags
4583a5f2100cc2b7109596d58fa12d2008a4cc33
Commit Graph
111 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
jiantw83andClaude Opus 5 197de62570 fix(issue-update): 網址夾帶私有提醒時擋下，並修正 TDZ 錯誤 
把上一次寫回的整行一起複製貼上是很常見的手誤，放行的話那句提醒會在議題上出現
兩次。

順帶修掉一個自己造出來的錯：PRIVACY_NOTE 原本宣告在 main() 之後，而新的檢查在
main() 的同步段就要用到它，於是每次執行都以「Cannot access 'PRIVACY_NOTE' before
initialization」收場。常數移到 main() 之前。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:30 +00:00
jiantw83andClaude Opus 5 57c059b5f9 docs(慣例): 寫明總覽模板是「模板不含邏輯」的唯一例外 
overview-artifact.html 是一份要在瀏覽器裡開的網頁，需要一段把 mermaid 畫出來的
腳本。與其默默違反自己寫的規則，不如把例外與理由寫進慣例表——下一個人才知道
這是想過的決定，而不是漏網的。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:30 +00:00
jiantw83andClaude Opus 5 0aa0439061 test(總覽網頁): 釘住模板結構與兩份正本的規則 
模板的檢查重點是「樣式與內容分離」與「全景段落能整段消失」，兩者壞掉時規劃版會
留下空標題或行內樣式散落各處，肉眼不容易發現。

順帶把 work-package 測試的 phase2 切法收斂到第三段之前——原本切到檔尾，第三段
新增的編號清單會混進段落順序的斷言裡。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:29 +00:00
jiantw83andClaude Opus 5 47529d33c2 test(issue-update): 覆蓋總覽網址的寫回與就地更新 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:29 +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 0e05dd2066 feat(issue-update): 支援 --overview-url，把總覽網址寫回議題 
沿用既有的 upsertLineInSection：連結以固定前綴獨佔總覽段落裡的一行，重跑時就地
更新，不會長出第二個連結；議題原本的 markdown 白話總覽一字不動——網頁是補充，
不是取代。

連結旁自動附上「此連結預設為私有，組織外無法開啟」。讀到的人多半會想轉寄給組織外
的人，這句話寫在議題上比寫在文件裡有用。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:28 +00:00
jiantw83andClaude Opus 5 ed2d08de9f feat(總覽模板): 新增圖解版總覽的 HTML 模板 
給非技術的利害關係人在會議上直接投影用：一句話總覽、目標、流程圖，分析階段再多
一張工作包全景。

樣式全部集中在單一 style 區塊，內文只放佔位——改版面不必動內容，換內容不必碰樣式。
深色模式跟隨系統，手機寬度另有斷點，投影與傳連結兩種場合都看得清楚。

工作包全景是整段佔位、獨佔一行，規劃階段填空字串時整段會乾淨消失；若把它包在寫死
的 section 裡，規劃版就會留下一個空標題。

mermaid 由 CDN 載入並實際渲染，而不是把原始碼丟給讀者看；代價是離線開啟時圖不會出來。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:22:27 +00:00
admin 34d5890126 Merge pull request 'feat/wp-schedule-and-board/main' (#31) from feat/wp-schedule-and-board/main into master 
Reviewed-on: #31
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-17 06:09:41 +00:00
jiantw83andClaude Opus 5 97d0afac38 test(project-add): 把「不建立專案」改成驗得出東西的斷言 
原本的條件是「沒有非 GET 請求打到路徑含 project 的端點」，但 Gitea 的專案根本
沒有 API 路徑，這個條件恆真，壞掉的實作也會通過。改成斷言真正的寫入只有議題本身
那一次 PATCH、而且只帶 projects 欄位。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:12 +00:00
jiantw83andClaude Opus 5 15da38a460 test(issue-update): 封住估算那一行的三種污染 
三條測試都先確認過會在舊版實作上失敗。第一版寫出來時有兩條其實是陪跑的——
情境裡沒有後續段落，正確與錯誤的結果剛好都落在 body 結尾，分不出來。加上一個
真正的後續段落之後才有鑑別力。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:11 +00:00
jiantw83andClaude Opus 5 b09746a309 test(排程): 覆蓋重複 index 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:11 +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 be6ceddde0 refactor(參數): parseIndex 抽到 lib，四支腳本共用 
同一段 /^[1-9]\d*$/ 與 BAD_INDEX 已經抄了四份。lib 本來就放著同性質的 parseRepo，
這一支該待在它旁邊。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:10 +00:00
jiantw83andClaude Opus 5 e5b247e4cf fix(排程): 拒絕重複的工作包 index 
同一個 index 出現兩次時，相依看的是後者、標題與人天卻取到前者，算出來的時程是
兩份定義混出來的東西，而且回傳 ok:true 完全不報錯。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:09 +00:00
jiantw83andClaude Opus 5 e494bd534e fix(議題解析): upsertLineInSection 限定在目標段落內 
三個實際重現過的污染情境：

- 圍欄裡的 `## 關聯` 被當成真標題，估算插進圍欄後面。本檔的共同前提是「圍欄裡的
  東西不是內容」，這支卻自己用 indexOf 找標題，繞過了那個判斷。
- `## 關聯度說明` 被 indexOf 當成 `## 關聯` 命中，改到別人的段落。
- 「這一行是否已存在」用整份 body 比對，於是別的段落剛好有 `估算人天：` 時被改掉，
  真正的關聯段落反而一直拿不到值。

改成沿用同檔的 eachLine 走行、標題要完全相同、既有那一行只在段落範圍內找。
弄錯的代價是靜靜改壞別人的內容，所以三道判斷都收緊。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:09 +00:00
jiantw83andClaude Opus 5 257642cb1c test(sdlc-analyze): 釘住第三段的腳本順序與已知限制那一節 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:08 +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 5327f5882e test(project-add): 覆蓋反查、貼網址、既有看板不被覆蓋 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:07 +00:00
jiantw83andClaude Opus 5 770bf686ce feat(project-add): 把議題放進看板，看板 id 靠掃議題反查 
Gitea 1.27 沒有「列出專案」的 endpoint，名稱只能反查：掃最近 50 筆議題，從它們
身上的 projects 欄位湊出 id→名稱對照。全都沒掛看板時湊不出來，這時請使用者直接
貼專案網址，結尾即 id。

projects 欄位是整份取代不是附加，所以要先讀出議題既有的看板再聯集——漏掉就等於
把這顆議題踢出原本的看板。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:06 +00:00
jiantw83andClaude Opus 5 3f97fe0901 test(issue-update): 覆蓋 Milestone 解析、日期格式與估算的就地更新 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:06 +00:00
jiantw83andClaude Opus 5 45bfd99d80 feat(issue-update): 掛 Milestone、寫截止日、記人天估算 
三件事經同一個 PATCH 送出，因為排時程時它們幾乎總是一起改，分開發等於多兩次往返。

Milestone 只認既有的：指到不存在的就中止並列出可選項目，本工具不建立 Milestone。

人天估算只寫進 body 的人類可讀一行。Gitea 1.27 的 API 沒有任何請求定義接受
time_estimate——它只出現在 Issue 的回應裡——所以議題的估算欄位無法由 API 寫入。
新增的 upsertLineInSection 負責就地更新那一行：重跑改估算不會累積成兩行，值沒變
就不把 body 塞進 PATCH，免得在議題上留下一筆沒有內容的編輯紀錄。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:05 +00:00
jiantw83andClaude Opus 5 b45437e527 test(issue-link): 覆蓋兩種相依、冪等與自我相依 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:05 +00:00
jiantw83andClaude Opus 5 b1025168c0 feat(issue-link): 建立議題之間的阻擋與先決 
--depends 是「這顆被誰擋住」，--blocks 是「這顆擋住誰」。先讀現況只補缺的那幾條，
重跑不會在 Gitea 上堆出重複的相依。

請求必須帶 owner 與 repo：Gitea 的相依端點少了它們會回 404，而且訊息是「repository
does not exist」，不看文件會以為是路徑寫錯。

自己依賴自己擋在發出請求之前——Gitea 會接受，但那會讓後續的拓撲排序永遠排不完。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:04 +00:00
jiantw83andClaude Opus 5 be477a4391 test(排程): 覆蓋拓撲順序、多重先決與成環 
除了逐例比對日期，另有一條測試直接驗「所有先決關係都滿足」這個不變式，
而不是只比對硬編的日期字串——不變式壞掉時它會指出是哪一對。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:04 +00:00
jiantw83andClaude Opus 5 0f53567737 feat(排程): 依相依關係拓撲推算截止日 
保證一件事：任一工作包的截止日都不早於它的先決。人工排時程最常出現的矛盾就是
前置工作比後續還晚到期，看板上看起來合理、實際上做不到。

以 Kahn 演算法排序，排不完就代表有環，而環上的成員正是排不進去的那些，直接把
它們列出來——相依成環是拆法有問題，硬排沒有意義。

日期以日曆日累加，不跳週末也不扣假日：跳過哪些日子是團隊政策，這裡不替使用者
決定。這支腳本不碰 Gitea 也不碰 git，純算數字，因此沒有前置檢查也不需要登入。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 06:06:03 +00:00
admin fa2540457f Merge pull request 'feat/work-package-issues/main' (#24) from feat/work-package-issues/main into master 
Reviewed-on: #24
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-17 05:46:19 +00:00
jiantw83andClaude Opus 5 6457d68874 refactor(測試): 模板結構的三項檢查抽到共用斷言 
段落順序、正本的編號清單、圖表段落不寫死圍欄——這三件事需求議題與工作包議題
都要驗，第二份模板出現時就該抽出來。兩份測試原本各抄一份，其中佔位數的斷言
還悄悄長成不同寫法（一邊 >=、一邊 ==）；抽出來之後這種分歧會被逼著講清楚。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:43:26 +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 7b54d566e2 docs(議題解析): 標明 tableSection 只處理兩欄 
工作包的介面契約是四欄（介面／產出者／消費者／形狀），直接沿用這一支會無聲
丟掉第三、四欄。把限制寫在函式註解上，讓接手 wp-extract 的人一眼看到，而不是
自己踩一次才發現。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:43:25 +00:00
jiantw83andClaude Opus 5 f0beb1ff64 test(工作包): 釘住模板與「產生工作包」那一段的規則 
模板的段落順序決定 wp-extract 解析得到什麼，待辦的巢狀寫法決定實作階段勾得到
哪一行——這兩件事寫死在測試裡，改動時才會被逼著一起改。

巢狀範例的斷言不比對固定縮排量，而是比對「最深的一層比最淺的深」，這樣重排
外層清單的縮排不會弄壞測試。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:43:25 +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 35bafcc928 feat(工作包): 新增工作包議題模板 
九個段落與順序：這個工作包在做什麼／描述／架構圖／範圍邊界／介面契約／待辦／
整體驗收／repo 列表／關聯。段落順序即下游 wp-extract 的解析依據。

介面契約是四欄表格（介面／產出者／消費者／形狀）並帶分隔列，讓解析有明確的
資料列起點。架構圖同樣不寫死 mermaid 圍欄——正本允許不畫，圍欄寫死時不畫會在
議題頁留下一塊渲染失敗的空區塊。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:43:24 +00:00
admin 2608da2b45 Merge pull request 'feat/sdlc-analyze-feasibility/main' (#23) from feat/sdlc-analyze-feasibility/main into master 
Reviewed-on: #23
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-17 05:35:05 +00:00
jiantw83andClaude Opus 5 8a405de189 test(sdlc-analyze): 覆蓋時程清單的估算前提 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:11:07 +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 2b06dfd663 test(sdlc-analyze): 釘住四份清單與正本的結構 
這一顆沒有腳本，交付的就是文件本身，所以驗的是文件的結構：四份清單各有足夠
的檢查項與提問指引、正本逐一指名它們且順序為架構→邏輯→資料→時程、一次一題、
兩個固定選項、共識摘要只印不寫，以及「不對 Gitea 寫入」有被寫成明確邊界。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:11:06 +00:00
jiantw83andClaude Opus 5 930270f545 refactor(測試): 正本的共用檢查抽到 helpers 
description 前綴、沒有 frontmatter、不出現平台專屬字樣——這三件事每一份流程
正本都要驗，第二份正本出現時就該抽出來，而不是再抄一次。順帶把讀正本、讀規則
正本、讀模板三個路徑組合也收在同一處。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:11:06 +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
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
admin 752c3825bf Merge pull request 'feat/issue-extract-contract/main' (#22) from feat/issue-extract-contract/main into master 
Reviewed-on: #22
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-17 05:04:33 +00:00
jiantw83andClaude Opus 5 06de8980ca test(issue-extract): 封住圍欄、表格與分頁的回頭路 
八條新案例，每一條都對應一個實際重現過的缺陷：~~~ 圍欄、圍欄內的假清單項、
混用圍欄標記、未閉合圍欄的歸屬、逸脫的直線、第二條分隔列、巢狀攤平，以及
留言分頁。

把修正還原成舊版解析器後，這批測試有五條會失敗；修正回來則全綠——確認測試
真的抓得到，不是陪跑。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:29 +00:00
jiantw83andClaude Opus 5 6125c2b6e0 fix(issue-extract): 留言逐頁讀完，不再只數第一頁 
原本只打一次留言端點就收工，留言超過一頁時未整併的則數會少算——而少算的後果
是下游以為描述是最新的，照著過期的描述做事。改用 lib.pages 走完所有頁，讀不完
就以 COMMENT_LIMIT 報錯，不無聲回傳半份。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:28 +00:00
jiantw83andClaude Opus 5 c8ecc39dc8 refactor(分頁): 把逐頁走訪抽成 lib.pages 
findIssueByTitle 原本自己寫了一份「翻到短頁為止、超過上限就報錯」的迴圈，
而新的留言走訪需要同一套規則。抽成非同步產生器之後，呼叫端仍能在找到目標時
提早離開，規則卻只寫一次。

錯誤碼與訊息由呼叫端指定：查重讀不完要講的是「可能重建議題」，數留言讀不完
要講的是「數不完未整併的則數」，處置不同就不該共用一句話。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:28 +00:00
jiantw83andClaude Opus 5 a5f28ec2c8 fix(議題解析): 圍欄與表格的邊界，五個會污染下游的解析缺陷 
code review 逐項驗出來的，全部可重現：

- `~~~` 圍欄完全沒被認出來，裡面的井字號會被當成段落標題。
- 段落內的圍欄不影響清單解析，於是程式碼範例裡的減號變成假的驗收標準。
  這是最嚴重的一個——輸出多出一條沒有人寫過的標準。
- 表格欄位裡逸脫的直線 `\|` 會把欄位切斷，內容整段消失。
- 同一段落裡若出現第二條分隔列，它會變成一筆 {term:'---'} 的假名詞。
- 圍欄開了沒關時，其後內容的歸屬沒有明確定義。

改法是把「圍欄裡的東西不是內容」這件事收斂到 eachLine 處理一次，段落切分、
清單、表格三者都靠它，而不是各自寫一份半套的判斷。圍欄需同種標記才算關閉；
沒關就到結尾時，其後內容一律算在圍欄內，這與 markdown 的實際渲染一致。

巢狀清單改為明確攤平並寫進註解：需求議題的模板沒有巢狀，真的出現時寧可多帶
一項，也不要無聲吃掉內容。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:28 +00:00
jiantw83andClaude Opus 5 fd80d9772a test(issue-extract): 以模板變體覆蓋抽取契約 
解析是整條鏈的上游，解析錯則下游全錯，所以模板變體餵得比別處雜：缺段落、
段落在但列表是空的、checkbox 已勾與未勾、中英混排、編號清單、名詞表只有
表頭、body 全空、出現契約外的段落。

留言的部分驗兩件事：未整併則數只算沒有 +1 的，以及留言內容一個字都不得出現
在輸出裡——後者用整份 stdout 做子字串比對，比逐欄檢查更難繞過。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:27 +00:00
jiantw83andClaude Opus 5 6254a6b53d feat(issue-extract): 建立需求議題的抽取契約 
下游（分析、實作）唯一的議題讀取管道，存在的理由是「不必吞下整份議題全文」。
輸出契約上的十四個欄位，缺少的段落回傳空值。

只讀 body，不把留言內容納入輸出，但回報未整併的留言則數，好讓下游知道自己是
不是在拿過期的描述做事。已整併的留言由 sdlc-sync 打上 +1 reaction，而 Gitea
的留言物件不含 reaction，只能逐則再查一次——請求數會隨留言數增長，但這個數字
要準。

議題不存在與沒有讀取權分成兩個錯誤碼：前者是輸入錯，後者要去改權限，處置不同
就不該共用一個碼。

Closes #5

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:27 +00:00
jiantw83andClaude Opus 5 0bac5ee186 feat(議題解析): 把議題 body 的 markdown 解析抽成純函式 
段落切分、列表、兩欄表格三種解析，需求議題與工作包議題共用同一套，
所以獨立成一支不碰網路也不碰檔案系統的模組，而不是塞進 lib。

段落切分會追蹤圍欄狀態：mermaid 或程式碼區塊裡的井字號不得被當成標題，
否則流程圖一畫，後面的段落就全被切碎。

缺段落回傳空值而非報錯——缺段落是模板的正常變體，不是解析失敗。
名詞表以分隔列為界，之後才是資料列，避免把表頭當成一筆名詞。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 05:00:26 +00:00
admin 9c3ba425e0 Merge pull request 'feat/sdlc-plan-requirement-issue/main' (#21) from feat/sdlc-plan-requirement-issue/main into master 
Reviewed-on: #21
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-17 04:51:02 +00:00
jiantw83andClaude Opus 5 9b9ab33a53 test(issue-create): 覆蓋建立議題與試跑預覽的契約 
沿用既有接縫：子行程執行、stub server 錄下每一筆請求。涵蓋標籤名稱解析、
未知標籤中止、不碰 labels 的寫入端點、同標題不重建、前後空白視為同一顆，
以及寫入型腳本一樣跑滿前置檢查。

試跑的部分特別驗「預覽要忠實」：預覽的 body 必須看得出標籤會被貼上、標籤
錯字在試跑就該擋下、同名議題已存在時預覽不得預告要建立議題，且全程不發出
任何寫入請求。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 04:44:47 +00:00
jiantw83andClaude Opus 5 9e57a5db99 test(sdlc-plan): 釘住正本與模板的結構 
正本與模板是檔案而非程式，卻是本工作包實際交付的東西：模板段落順序決定下游
解析得到什麼，正本的平台中立性決定轉接檔能不能一份寫到底。以測試釘住段落
順序、佔位格式、description 前綴、平台專屬字樣的缺席、流程圖的上限，以及
模板不得寫死 mermaid 圍欄。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 04:44:47 +00:00