Problem Statement
倉庫裡有兩套掃 Markdown 端點的程式,判準不同,而分歧沒有被記錄成刻意的:
|
source_facts/markdown.py |
markdown_drafts/markdown.py |
| 比對方式 |
^ 錨定的 match(宣告必須在行首) |
search(行內任何位置) |
| method 大小寫 |
大寫字面量,大小寫敏感 |
re.IGNORECASE |
| 表頭比對 |
第一欄需「像名稱」的嚴格判準 |
另一套 |
| 範例區塊 |
語言白名單 |
另一套 |
實際後果不只是風格不一致:benchmarks/rsg-game-transfer-wallet 那份被壓平成單行的來源,source_facts 掃出零筆(行首錨定,宣告在第 1 行中間),而 drafts 那套的 search 判準會找到它。也就是說,同一份來源在兩個子系統眼中的「有沒有端點」是相反的。
兩者用途不同(source_facts 餵 fail-closed 閘門,drafts 是非權威草稿),嚴格程度不同是合理的——問題在於沒有任何地方寫下哪一條分歧是刻意的、為什麼。下一個維護者無從判斷該把哪一套改成另一套。
Acceptance criteria
Notes
來自 #73 的 Out of Scope(「不統一兩套 Markdown 掃描器的規則分歧」)。
Problem Statement
倉庫裡有兩套掃 Markdown 端點的程式,判準不同,而分歧沒有被記錄成刻意的:
source_facts/markdown.pymarkdown_drafts/markdown.py^錨定的match(宣告必須在行首)search(行內任何位置)re.IGNORECASE實際後果不只是風格不一致:
benchmarks/rsg-game-transfer-wallet那份被壓平成單行的來源,source_facts掃出零筆(行首錨定,宣告在第 1 行中間),而 drafts 那套的search判準會找到它。也就是說,同一份來源在兩個子系統眼中的「有沒有端點」是相反的。兩者用途不同(
source_facts餵 fail-closed 閘門,drafts 是非權威草稿),嚴格程度不同是合理的——問題在於沒有任何地方寫下哪一條分歧是刻意的、為什麼。下一個維護者無從判斷該把哪一套改成另一套。Acceptance criteria
source_facts的嚴格度——放寬會生出假事實,那是 ADR 0007 的否決項Notes
來自 #73 的 Out of Scope(「不統一兩套 Markdown 掃描器的規則分歧」)。