：用 bug-fix 模板把一次 Bug 修復寫成可驗證的工程切片)
人工智能AI Agent多智能體Agent 編排代碼智能體CLI【免費下載鏈接】openrigMulti-agent harness that runs Claude Code and Codex together as one system項目地址https://gitcode.com/GitHub_Trending/op/openrig點擊查看免費下載本篇技術(shù)指南圍繞 OpenRig 內(nèi)置的缺陷修復切片模板bug-fix展開它是 OpenRig 的 Slice切片腳手架家族中專用于 Bug 修復的一等模板當你運行rig scope slice create并指定--template bug-fix時CLI 會依據(jù)它生成一份結(jié)構(gòu)完整的SPEC.md其中自帶 Intent、Mini-requirements、Proof contract 以及經(jīng)典的 Repro/Expected/Actual 三段式問題描述。讀完本文你將掌握該模板的每一處占位符、每一條章節(jié)的寫法與約束理解它如何與rig proof add、rig scope audit、SDLC 約定docs/reference/sdlc-conventions.md及系統(tǒng)性調(diào)試技能協(xié)同把修一個 Bug從一句口頭訴求變成一條可追蹤、可審計、有證據(jù)閉環(huán)的工程切片。一、模板的定位bug-fix 在 Slice 模板家族中的角色OpenRig 把可交付工作拆成Mission任務(wù)→ Slice切片兩層。Slice 是承載一次具體交付的最小工作單元而rig scope slice create在創(chuàng)建切片時通過--template決定SPEC.md的初始骨架。在 packages/cli/src/lib/scope/types.ts 中Slice 模板的合法取值被定義為一個封閉集合export type SliceTemplateKind | placeholder | bug-fix | backlog-deprecation | backlog-tech-debt | release-feature | research;也就是說bug-fix與placeholder、backlog-deprecation、backlog-tech-debt、release-feature、research并列是模板家族中專門服務(wù)缺陷修復這一工作形態(tài)的成員。它的設(shè)計意圖很明確對于一次 Bug 修復模板允許整份計劃就是一次可觀察的修復結(jié)果模板原文中 Mini-requirements 的提示語就是 The fix as an observable outcome. For a bug fix this may BE the whole plan.同時強制要求提供可復現(xiàn)步驟、預期/實際行為、影響面與修復提案讓一次修復從一開始就具備可驗證性。在 OpenRig 的語義里Slice 不只是一個任務(wù)卡片一次rig scope slice create會同時落下一組配套文件SPEC.md、slice.yaml、PROGRESS.md、PROOF.md、proof/目錄這部分在 packages/cli/test/scope-convention-scaffold.test.ts 中被逐模板斷言為固定產(chǎn)物集合。bug-fix 模板生成的正是這一整套可審計切片的入口文檔。二、模板的物理位置與加載機制模板本體位于 packages/cli/src/lib/scope-templates/bug-fix.md與其余 Slice/Mission 模板同目錄存放。它之所以能以.md形式被 CLI 讀取是因為加載器在 packages/cli/src/lib/scope/templates.ts 中通過fileURLToPath直接按候選根解析文件路徑——開發(fā)態(tài)src/lib/scope/的上級scope-templates/、構(gòu)建態(tài)dist/lib/scope/的上級與發(fā)布包回退路徑依次探測第一個存在的目錄勝出從而保證本地開發(fā)與安裝包兩種布局下都能找到模板。渲染時templates.ts 的applyPlaceholders會做純文本占位符替換{{id}}、{{slice_number}}、{{slug}}、{{mission}}、{{title}}、{{created_date}}、{{intent_yaml}}、{{intent}}、{{depends_on}}等隨后renderSliceTemplate(kind, opts)依據(jù)kind如bug-fix拼出模板文件名并返回渲染后的正文。也就是說模板文件是以文檔形式存在、由代碼驅(qū)動渲染的單一事實來源修改模板即修改腳手架行為。三、逐節(jié)拆解 bug-fix 模板frontmatter 與六個正文小節(jié)3.1 frontmatter切片的身份與元數(shù)據(jù)模板頭部是一段 YAML frontmatter所有字段在rig scope slice create時由渲染器自動填入無需手工編寫字段填充來源說明idsliceIdFromMission(missionId, nn)穩(wěn)定點號 ID形如OPR.0.3.2.2項目前綴 版本 序號規(guī)則見 packages/cli/src/lib/scope/dot-id.tssliceNN-slug目錄名后綴如05-perf-fixNN 由nextSliceNN自動尋找永不復用已用編號mission命令參數(shù)所屬 Mission 的文件夾名如release-0.3.2status固定值placeholder切片創(chuàng)建時的初始狀態(tài)stage固定值wip認識論成熟度階段合法枚舉見types.ts的STAGE_VALUESwip/provisional/established/canonical/superseded/retiredverified{{created_date}} against scaffold (rig scope create)記錄此文件僅經(jīng)過腳手架驗證的事實防止把模板占位當成已實現(xiàn)created{{created_date}}創(chuàng)建日期ISOintent--intent參數(shù)以 JSON 字符串形式寫入的意圖聲明缺省回退為標題depends_on--depends-on參數(shù)兄弟切片點號 ID 數(shù)組渲染為 JSONscope.ts會校驗其必須是本 Mission 前綴下的合法 slice 點號 ID3.2 正文六段從意圖到修復提案模板正文在# Slice {{slice_number}} — {{title}}標題之后依次展開六個 H2 小節(jié)## Intent—— 一句或一小段話說明為什么要修。來自--intent參數(shù)缺省等于標題。## Mini-requirements—— 一瞥即懂的需求層用編號的可觀察結(jié)果表達。對于 Bug 修復模板明示這一條可能就是整份計劃The fix as an observable outcome。## Proof contract—— 證明契約用復選框- [ ]逐條寫下承諾的可觀察交付物。模板給出的示例行是[The repro no longer reproduces / the regression test pins it — captured. Pair with proof via rig proof add … --evidences (media attached with --media).]提示兩條典型的 Bug 修復證據(jù)復現(xiàn)不再出現(xiàn)或回歸測試釘住了該行為并指明證據(jù)須經(jīng)rig proof add落盤、媒體用--media附帶。## Repro/## Expected/## Actual—— 經(jīng)典的缺陷三要素復現(xiàn)步驟、預期行為、實際行為。這是模板對 Bug 修復工作形態(tài)最直接的適配直接對應能否穩(wěn)定復現(xiàn)這一調(diào)試鐵律。## Impact—— 誰受影響、嚴重程度如何用于支撐優(yōu)先級判斷。## Fix proposal—— 可選的修復思路模板標注 Optional不強制。四、真實使用流程從命令到磁盤上的切片4.1 創(chuàng)建命令與參數(shù)rig scope slice create在 packages/cli/src/commands/scope.ts 中定義語法為rig scope slice create mission slug [options]常用選項選項作用--template kind模板種類合法值見SLICE_TEMPLATE_KINDS默認placeholderBug 修復請顯式傳bug-fix--title text顯示標題缺省為 slug 的標題化結(jié)果titleFromSlug--intent text寫入 SPEC.md frontmatter 的意圖缺省等于標題--depends-on dot-id...聲明對兄弟切片點號 ID 的構(gòu)建順序依賴--readme-only只寫progress_rail: readme-only標記不腳手架PROGRESS.md--json輸出機器可讀結(jié)果一個真實的創(chuàng)建示例rig scope slice create release-0.3.2 perf-fix \ --template bug-fix \ --title Fix agent-seat double-attach deadlock \ --intent Two agents attaching the same seat must not deadlock the seat registry \ --depends-on OPR.0.3.2.1創(chuàng)建過程scope.ts會依次定位 Mission → 計算下一個 NN如05→ 拼出切片目錄slices/05-perf-fix/→ 校驗依賴點號 ID → 渲染模板 → 在同一事務(wù)邊界內(nèi)寫入SPEC.md、PROGRESS.md、slice.yaml、PROOF.md并創(chuàng)建空proof/目錄任何一步失敗都會回滾整個目錄與父 Mission 的寫入絕不留下半成品。4.2 命令行為有測試背書packages/cli/test/scope-commands.test.ts 的 HG-4 用例直接驗證了本模板以--template bug-fix創(chuàng)建切片后讀回SPEC.md必須包含## Repro與## Expected小節(jié)。同文件還斷言了PROGRESS.md默認生成AC-1以及根級PROOF.md 空proof/目錄的腳手架行為OPR.0.4.1.23。這些測試共同保證了模板 → 文件系統(tǒng)這條鏈路的穩(wěn)定性。4.3 落地后的目錄結(jié)構(gòu)一次創(chuàng)建后切片目錄如下slices/05-perf-fix/ ├── SPEC.md # 由 bug-fix 模板渲染出的切片說明本模板的核心產(chǎn)物 ├── slice.yaml # slice 清單spec: SPEC.md / progress: PROGRESS.md / proof: PROOF.md ├── PROGRESS.md # 驗收狀態(tài)軌Acceptance 復選框 ├── PROOF.md # 收尾時填寫的證明摘要綁定 SPEC.md 的證明契約 └── proof/ # 證明工件目錄截圖、錄屏、命令輸出等媒體五、模板占位與真寫的邊界審計如何識別偷懶模板中的方括號文本如[Steps to reproduce]、[Expected behavior]不是普通的待辦說明而是被專門識別的腳手架占位符標記。packages/cli/src/lib/scope/scaffold-placeholder.ts 定義了唯一語法文本去除首尾空白后若整體被方括號包裹^\[.*\]$即判定為腳手架占位、非作者內(nèi)容。該判定同時被 scope audit、review compose、slice-detail projector 三方消費且該文件在 CLI 與 daemon 兩個包中是字節(jié)等價的雙胞胎twin由 CI 強制保持一致。這意味著直接照抄模板把[Expected behavior]留在SPEC.md里審計時不會算作已撰寫內(nèi)容。rig scope audit實現(xiàn)在 packages/cli/src/lib/scope/scope-audit.ts會據(jù)此給出相應 findingmini_requirements_missing_or_malformedlow## Mini-requirements缺失或雖有編號列表但全是占位文本proof_contract_missing_or_malformedlow## Proof contract缺失或復選框行全是占位文本scope-audit.ts要求至少有一條作者撰寫的復選框項才算有效契約missing_proofmedium切片已處于 done/proven 狀態(tài)卻缺少根級PROOF.md且proof/目錄為空packages/cli/test/scope-audit.test.ts 有對應用例。因此把模板落盤之后的第一步工作就是用真實內(nèi)容替換每一處方括號占位。審計對 Bug 修復切片的直接意義是Repro/Expected/Actual 與證明契約缺一不可占位不算數(shù)。六、證據(jù)閉環(huán)rig proof add與 PROOF.mdbug-fix 模板的 Proof contract 提示語明確要求證據(jù)經(jīng)由rig proof add … --evidences媒體用--media落盤而絕不手工放置。對應命令實現(xiàn)在 packages/cli/src/commands/proof.tsrig proof add slice \ --artifact-type qa \ --verdict PASS \ --candidate-sha the-proven-tip \ --money-evidence one line of money evidence \ --file artifact.md \ --evidences 1 \ --media screenshot-01.png,regression-output.txt \ --self-check I looked at the captures; they show the claim關(guān)鍵參數(shù)與約束--artifact-type與--verdict是兩個封閉集合ratified closed sets按 docs/reference/sdlc-conventions.md 的 B3 節(jié)擴展它們屬于約定變更而非本地編輯artifact_type ∈ guard | qa | rev1-r1 | rev1-r2 | adjudicationverdict ∈ CLEAR | BLOCKING | CONCERNING | PASS | NOT-CLEAR--candidate-sha是 C1 頭的聯(lián)結(jié)鍵join key該工件所評判的被證明候選提交--evidences指明本次 drop 覆蓋證明契約中的哪些條目條目文本或 1 基索引該引用由logical-checkbox語法packages/cli/src/lib/scope/logical-checkbox.ts統(tǒng)一解析——review 合成、切片詳情投影與 CLI 證據(jù)索引校驗共用同一套語法保證按索引引用時各方指向同一條承諾項--media中的媒體路徑必須是相對于切片proof/目錄的相對路徑proof.ts在 drop 時即校驗其非絕對路徑且不逃逸切片目錄--self-check記錄代理確實看過證據(jù)的聲明。落盤后工件獲得合法的 C1 頭五個必填字段slice、candidate_sha、artifact_type、verdict、money_evidence。與之配套的收尾文檔模板是 packages/cli/src/lib/scope-templates/proof.md它要求寫明這證明了什么、工件清單媒體置于proof/下以及殘留問題Residue / caveats并由 impl/QA 結(jié)對在切片收尾時填寫。直接往proof/丟文件而不走 drop是文檔明示的反模式——交付物會停留在未配對、unverified狀態(tài)審計也會照實標記。七、SOP 遵從模板底部的怎么干這個切片bug-fix 模板底部附有一段 SOP 指引它把模板與 OpenRig 的 SDLC 約定體系連成一體。核心指向是約定 SSOTdocs/reference/sdlc-conventions.md安裝包內(nèi)位于$OPENRIG_HOME/reference/sdlc-conventions.md。按該文檔工作方式是一份組件菜單而非流水線構(gòu)建路徑三選一簡單默認流Part A默認且始終適用、wave 模型切片在互不重疊的文件領(lǐng)域并行構(gòu)建、集成者串行合并、獨立評審見 docs/reference/wave-sdlc.md、以及被指派的嚴格覆蓋層Part B僅當人類操作者或中繼該決定的中樞把重路徑指派給具名工作時才可啟用代理不得自行選擇 Part B證明契約、plan-lock、C1 drop、proof-lock 都在 Part B。規(guī)劃嚴格度旋鈕 P0–P4按工作性質(zhì)撥動P0 只要 mini-requirements 與指針簡單、可逆的工作P1 是帶證明契約的規(guī)范默認P2 在規(guī)范凍結(jié)前增加研究輪P3 增加非作者的對抗性評審并讓修正落入證明契約P4 則要求從零盲寫的設(shè)計稿與先前方案對比。完整參考見 docs/reference/planning-dial.md。默認流的完整教學由mission-slice-sop技能提供對應 Part A 的簡單 SDLC。所有路徑的共同底線進度記錄在PROGRESS.md狀態(tài)枚舉active | done | blocked見 packages/cli/src/lib/scope/progress-edit.ts證據(jù)一律經(jīng)rig proof add落盤、絕不手工放置切片在承諾的可觀察結(jié)果擁有證據(jù)之前不算完成最終以rig scope audit校驗。對一次 Bug 修復切片而言SOP 的落地順序通常為用 bug-fix 模板腳手架 → 替換占位、寫實 Repro/Expected/Actual 與證明契約 → 按 P 撥號選擇規(guī)劃嚴格度 → 修復過程中在PROGRESS.md記錄狀態(tài) → 用rig proof add提交復現(xiàn)消失或回歸測試命中的證據(jù) → 收尾時填寫PROOF.md→rig scope audit復核。八、與系統(tǒng)性調(diào)試技能的自然銜接bug-fix 模板的 Repro/Expected/Actual 結(jié)構(gòu)與 OpenRig 內(nèi)置的 skills/_canonical/process/systematic-debugging/SKILL.md 形成天然互補該技能的鐵律是先找根因再動手修癥狀修復就是失敗其 Phase 1 明確要求穩(wěn)定復現(xiàn)Reproduce Consistently、細讀錯誤信息、檢查近期變更、在多組件系統(tǒng)中逐層取證。這些恰好是模板中Repro、Expected、Actual、Impact四節(jié)要沉淀的內(nèi)容——模板負責把調(diào)試紀律固化成文檔結(jié)構(gòu)技能負責指導填出高質(zhì)量內(nèi)容。而模板 Proof contract 提示的repro 不再復現(xiàn) / 回歸測試釘住行為兩種證據(jù)形態(tài)也正是該技能 Phase 4修根因而非癥狀的可驗證外化。九、小結(jié)bug-fix 模板的完整閉環(huán)把全部環(huán)節(jié)串起來一次符合規(guī)范的 Bug 修復切片走的是這樣一條證據(jù)鏈rig scope slice create mission slug --template bug-fix生成SPEC.md含 frontmatter 點號 ID、Intent、Mini-requirements、Proof contract、Repro/Expected/Actual、Impact、Fix proposal并同步落盤slice.yaml、PROGRESS.md、PROOF.md、proof/用真實內(nèi)容替換全部方括號占位——占位會被 scaffold-placeholder.ts 識別不算作者內(nèi)容按 sdlc-conventions.md 的組件菜單選擇構(gòu)建路徑與 P0–P4 嚴格度在PROGRESS.md持續(xù)跟蹤用rig proof add以 C1 頭落盤證據(jù)--evidences回指證明契約條目、--media附帶proof/下媒體收尾填寫PROOF.mdrig scope audit最終校驗切片在證據(jù)齊備前不算 done。這套機制的獨特之處在于bug-fix 模板不是一張待填表格而是一條被渲染器、審計器、證明命令三方共同約束的契約——它讓修 Bug這件在傳統(tǒng)工程里最容易被口頭交代、事后無法追證的工作在 OpenRig 中獲得了與功能開發(fā)同等的結(jié)構(gòu)、證據(jù)與可審計性。贊分享人工智能AI Agent多智能體Agent 編排代碼智能體CLI【免費下載鏈接】openrigMulti-agent harness that runs Claude Code and Codex together as one system項目地址https://gitcode.com/GitHub_Trending/op/openrig點擊查看免費下載相關(guān)推薦OpenRig 技術(shù)債務(wù)治理實戰(zhàn)用 backlog-tech-debt Slice 模板把存量債變成可審計、可驗證的工作切片OpenRig 技術(shù)債務(wù)治理實戰(zhàn)用 backlog tech debt Slice 模板把存量債變成可審計、可驗證的工作切片 本文圍繞 OpenRig 倉庫中人工智能AI Agent多智能體Agent 編排代碼智能體CLI別再讓Issue被關(guān)閉用openJiuwen缺陷報告模板寫出快速被復現(xiàn)修復的Bug別再讓Issue被關(guān)閉用openJiuwen缺陷報告模板寫出快速被復現(xiàn)修復的Bug 提交過開源項目Issue的朋友可能都有過這樣的經(jīng)歷滿懷期待地報了一個BECC 缺陷修復編排指南用 /orch-fix-defect 實現(xiàn)紅測試驅(qū)動的 Bug 修復ECC 缺陷修復編排指南用 /orch fix defect 實現(xiàn)紅測試驅(qū)動的 Bug 修復 本文以 ECCThe agent harness perfor人工智能AI 技能AI 插件AI 評測Agent 評測MCP Clients開發(fā)工具創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 OpenRig 缺陷修復 Slice 模板實戰(zhàn)：用 bug-fix 模板把一次 Bug 修復寫成可驗證的工程切片
人工智能AI Agent多智能體Agent 編排代碼智能體CLI【免費下載鏈接】openrigMulti-agent harness that runs Claude Code and Codex together as one system項目地址https://gitcode.com/GitHub_Trending/op/openrig點擊查看免費下載本篇技術(shù)指南圍繞 OpenRig 內(nèi)置的缺陷修復切片模板bug-fix展開它是 OpenRig 的 Slice切片腳手架家族中專用于 Bug 修復的一等模板當你運行rig scope slice create并指定--template bug-fix時CLI 會依據(jù)它生成一份結(jié)構(gòu)完整的SPEC.md其中自帶 Intent、Mini-requirements、Proof contract 以及經(jīng)典的 Repro/Expected/Actual 三段式問題描述。讀完本文你將掌握該模板的每一處占位符、每一條章節(jié)的寫法與約束理解它如何與rig proof add、rig scope audit、SDLC 約定docs/reference/sdlc-conventions.md及系統(tǒng)性調(diào)試技能協(xié)同把修一個 Bug從一句口頭訴求變成一條可追蹤、可審計、有證據(jù)閉環(huán)的工程切片。一、模板的定位bug-fix 在 Slice 模板家族中的角色OpenRig 把可交付工作拆成Mission任務(wù)→ Slice切片兩層。Slice 是承載一次具體交付的最小工作單元而rig scope slice create在創(chuàng)建切片時通過--template決定SPEC.md的初始骨架。在 packages/cli/src/lib/scope/types.ts 中Slice 模板的合法取值被定義為一個封閉集合export type SliceTemplateKind | placeholder | bug-fix | backlog-deprecation | backlog-tech-debt | release-feature | research;也就是說bug-fix與placeholder、backlog-deprecation、backlog-tech-debt、release-feature、research并列是模板家族中專門服務(wù)缺陷修復這一工作形態(tài)的成員。它的設(shè)計意圖很明確對于一次 Bug 修復模板允許整份計劃就是一次可觀察的修復結(jié)果模板原文中 Mini-requirements 的提示語就是 The fix as an observable outcome. For a bug fix this may BE the whole plan.同時強制要求提供可復現(xiàn)步驟、預期/實際行為、影響面與修復提案讓一次修復從一開始就具備可驗證性。在 OpenRig 的語義里Slice 不只是一個任務(wù)卡片一次rig scope slice create會同時落下一組配套文件SPEC.md、slice.yaml、PROGRESS.md、PROOF.md、proof/目錄這部分在 packages/cli/test/scope-convention-scaffold.test.ts 中被逐模板斷言為固定產(chǎn)物集合。bug-fix 模板生成的正是這一整套可審計切片的入口文檔。二、模板的物理位置與加載機制模板本體位于 packages/cli/src/lib/scope-templates/bug-fix.md與其余 Slice/Mission 模板同目錄存放。它之所以能以.md形式被 CLI 讀取是因為加載器在 packages/cli/src/lib/scope/templates.ts 中通過fileURLToPath直接按候選根解析文件路徑——開發(fā)態(tài)src/lib/scope/的上級scope-templates/、構(gòu)建態(tài)dist/lib/scope/的上級與發(fā)布包回退路徑依次探測第一個存在的目錄勝出從而保證本地開發(fā)與安裝包兩種布局下都能找到模板。渲染時templates.ts 的applyPlaceholders會做純文本占位符替換{{id}}、{{slice_number}}、{{slug}}、{{mission}}、{{title}}、{{created_date}}、{{intent_yaml}}、{{intent}}、{{depends_on}}等隨后renderSliceTemplate(kind, opts)依據(jù)kind如bug-fix拼出模板文件名并返回渲染后的正文。也就是說模板文件是以文檔形式存在、由代碼驅(qū)動渲染的單一事實來源修改模板即修改腳手架行為。三、逐節(jié)拆解 bug-fix 模板frontmatter 與六個正文小節(jié)3.1 frontmatter切片的身份與元數(shù)據(jù)模板頭部是一段 YAML frontmatter所有字段在rig scope slice create時由渲染器自動填入無需手工編寫字段填充來源說明idsliceIdFromMission(missionId, nn)穩(wěn)定點號 ID形如OPR.0.3.2.2項目前綴 版本 序號規(guī)則見 packages/cli/src/lib/scope/dot-id.tssliceNN-slug目錄名后綴如05-perf-fixNN 由nextSliceNN自動尋找永不復用已用編號mission命令參數(shù)所屬 Mission 的文件夾名如release-0.3.2status固定值placeholder切片創(chuàng)建時的初始狀態(tài)stage固定值wip認識論成熟度階段合法枚舉見types.ts的STAGE_VALUESwip/provisional/established/canonical/superseded/retiredverified{{created_date}} against scaffold (rig scope create)記錄此文件僅經(jīng)過腳手架驗證的事實防止把模板占位當成已實現(xiàn)created{{created_date}}創(chuàng)建日期ISOintent--intent參數(shù)以 JSON 字符串形式寫入的意圖聲明缺省回退為標題depends_on--depends-on參數(shù)兄弟切片點號 ID 數(shù)組渲染為 JSONscope.ts會校驗其必須是本 Mission 前綴下的合法 slice 點號 ID3.2 正文六段從意圖到修復提案模板正文在# Slice {{slice_number}} — {{title}}標題之后依次展開六個 H2 小節(jié)## Intent—— 一句或一小段話說明為什么要修。來自--intent參數(shù)缺省等于標題。## Mini-requirements—— 一瞥即懂的需求層用編號的可觀察結(jié)果表達。對于 Bug 修復模板明示這一條可能就是整份計劃The fix as an observable outcome。## Proof contract—— 證明契約用復選框- [ ]逐條寫下承諾的可觀察交付物。模板給出的示例行是[The repro no longer reproduces / the regression test pins it — captured. Pair with proof via rig proof add … --evidences (media attached with --media).]提示兩條典型的 Bug 修復證據(jù)復現(xiàn)不再出現(xiàn)或回歸測試釘住了該行為并指明證據(jù)須經(jīng)rig proof add落盤、媒體用--media附帶。## Repro/## Expected/## Actual—— 經(jīng)典的缺陷三要素復現(xiàn)步驟、預期行為、實際行為。這是模板對 Bug 修復工作形態(tài)最直接的適配直接對應能否穩(wěn)定復現(xiàn)這一調(diào)試鐵律。## Impact—— 誰受影響、嚴重程度如何用于支撐優(yōu)先級判斷。## Fix proposal—— 可選的修復思路模板標注 Optional不強制。四、真實使用流程從命令到磁盤上的切片4.1 創(chuàng)建命令與參數(shù)rig scope slice create在 packages/cli/src/commands/scope.ts 中定義語法為rig scope slice create mission slug [options]常用選項選項作用--template kind模板種類合法值見SLICE_TEMPLATE_KINDS默認placeholderBug 修復請顯式傳bug-fix--title text顯示標題缺省為 slug 的標題化結(jié)果titleFromSlug--intent text寫入 SPEC.md frontmatter 的意圖缺省等于標題--depends-on dot-id...聲明對兄弟切片點號 ID 的構(gòu)建順序依賴--readme-only只寫progress_rail: readme-only標記不腳手架PROGRESS.md--json輸出機器可讀結(jié)果一個真實的創(chuàng)建示例rig scope slice create release-0.3.2 perf-fix \ --template bug-fix \ --title Fix agent-seat double-attach deadlock \ --intent Two agents attaching the same seat must not deadlock the seat registry \ --depends-on OPR.0.3.2.1創(chuàng)建過程scope.ts會依次定位 Mission → 計算下一個 NN如05→ 拼出切片目錄slices/05-perf-fix/→ 校驗依賴點號 ID → 渲染模板 → 在同一事務(wù)邊界內(nèi)寫入SPEC.md、PROGRESS.md、slice.yaml、PROOF.md并創(chuàng)建空proof/目錄任何一步失敗都會回滾整個目錄與父 Mission 的寫入絕不留下半成品。4.2 命令行為有測試背書packages/cli/test/scope-commands.test.ts 的 HG-4 用例直接驗證了本模板以--template bug-fix創(chuàng)建切片后讀回SPEC.md必須包含## Repro與## Expected小節(jié)。同文件還斷言了PROGRESS.md默認生成AC-1以及根級PROOF.md 空proof/目錄的腳手架行為OPR.0.4.1.23。這些測試共同保證了模板 → 文件系統(tǒng)這條鏈路的穩(wěn)定性。4.3 落地后的目錄結(jié)構(gòu)一次創(chuàng)建后切片目錄如下slices/05-perf-fix/ ├── SPEC.md # 由 bug-fix 模板渲染出的切片說明本模板的核心產(chǎn)物 ├── slice.yaml # slice 清單spec: SPEC.md / progress: PROGRESS.md / proof: PROOF.md ├── PROGRESS.md # 驗收狀態(tài)軌Acceptance 復選框 ├── PROOF.md # 收尾時填寫的證明摘要綁定 SPEC.md 的證明契約 └── proof/ # 證明工件目錄截圖、錄屏、命令輸出等媒體五、模板占位與真寫的邊界審計如何識別偷懶模板中的方括號文本如[Steps to reproduce]、[Expected behavior]不是普通的待辦說明而是被專門識別的腳手架占位符標記。packages/cli/src/lib/scope/scaffold-placeholder.ts 定義了唯一語法文本去除首尾空白后若整體被方括號包裹^\[.*\]$即判定為腳手架占位、非作者內(nèi)容。該判定同時被 scope audit、review compose、slice-detail projector 三方消費且該文件在 CLI 與 daemon 兩個包中是字節(jié)等價的雙胞胎twin由 CI 強制保持一致。這意味著直接照抄模板把[Expected behavior]留在SPEC.md里審計時不會算作已撰寫內(nèi)容。rig scope audit實現(xiàn)在 packages/cli/src/lib/scope/scope-audit.ts會據(jù)此給出相應 findingmini_requirements_missing_or_malformedlow## Mini-requirements缺失或雖有編號列表但全是占位文本proof_contract_missing_or_malformedlow## Proof contract缺失或復選框行全是占位文本scope-audit.ts要求至少有一條作者撰寫的復選框項才算有效契約missing_proofmedium切片已處于 done/proven 狀態(tài)卻缺少根級PROOF.md且proof/目錄為空packages/cli/test/scope-audit.test.ts 有對應用例。因此把模板落盤之后的第一步工作就是用真實內(nèi)容替換每一處方括號占位。審計對 Bug 修復切片的直接意義是Repro/Expected/Actual 與證明契約缺一不可占位不算數(shù)。六、證據(jù)閉環(huán)rig proof add與 PROOF.mdbug-fix 模板的 Proof contract 提示語明確要求證據(jù)經(jīng)由rig proof add … --evidences媒體用--media落盤而絕不手工放置。對應命令實現(xiàn)在 packages/cli/src/commands/proof.tsrig proof add slice \ --artifact-type qa \ --verdict PASS \ --candidate-sha the-proven-tip \ --money-evidence one line of money evidence \ --file artifact.md \ --evidences 1 \ --media screenshot-01.png,regression-output.txt \ --self-check I looked at the captures; they show the claim關(guān)鍵參數(shù)與約束--artifact-type與--verdict是兩個封閉集合ratified closed sets按 docs/reference/sdlc-conventions.md 的 B3 節(jié)擴展它們屬于約定變更而非本地編輯artifact_type ∈ guard | qa | rev1-r1 | rev1-r2 | adjudicationverdict ∈ CLEAR | BLOCKING | CONCERNING | PASS | NOT-CLEAR--candidate-sha是 C1 頭的聯(lián)結(jié)鍵join key該工件所評判的被證明候選提交--evidences指明本次 drop 覆蓋證明契約中的哪些條目條目文本或 1 基索引該引用由logical-checkbox語法packages/cli/src/lib/scope/logical-checkbox.ts統(tǒng)一解析——review 合成、切片詳情投影與 CLI 證據(jù)索引校驗共用同一套語法保證按索引引用時各方指向同一條承諾項--media中的媒體路徑必須是相對于切片proof/目錄的相對路徑proof.ts在 drop 時即校驗其非絕對路徑且不逃逸切片目錄--self-check記錄代理確實看過證據(jù)的聲明。落盤后工件獲得合法的 C1 頭五個必填字段slice、candidate_sha、artifact_type、verdict、money_evidence。與之配套的收尾文檔模板是 packages/cli/src/lib/scope-templates/proof.md它要求寫明這證明了什么、工件清單媒體置于proof/下以及殘留問題Residue / caveats并由 impl/QA 結(jié)對在切片收尾時填寫。直接往proof/丟文件而不走 drop是文檔明示的反模式——交付物會停留在未配對、unverified狀態(tài)審計也會照實標記。七、SOP 遵從模板底部的怎么干這個切片bug-fix 模板底部附有一段 SOP 指引它把模板與 OpenRig 的 SDLC 約定體系連成一體。核心指向是約定 SSOTdocs/reference/sdlc-conventions.md安裝包內(nèi)位于$OPENRIG_HOME/reference/sdlc-conventions.md。按該文檔工作方式是一份組件菜單而非流水線構(gòu)建路徑三選一簡單默認流Part A默認且始終適用、wave 模型切片在互不重疊的文件領(lǐng)域并行構(gòu)建、集成者串行合并、獨立評審見 docs/reference/wave-sdlc.md、以及被指派的嚴格覆蓋層Part B僅當人類操作者或中繼該決定的中樞把重路徑指派給具名工作時才可啟用代理不得自行選擇 Part B證明契約、plan-lock、C1 drop、proof-lock 都在 Part B。規(guī)劃嚴格度旋鈕 P0–P4按工作性質(zhì)撥動P0 只要 mini-requirements 與指針簡單、可逆的工作P1 是帶證明契約的規(guī)范默認P2 在規(guī)范凍結(jié)前增加研究輪P3 增加非作者的對抗性評審并讓修正落入證明契約P4 則要求從零盲寫的設(shè)計稿與先前方案對比。完整參考見 docs/reference/planning-dial.md。默認流的完整教學由mission-slice-sop技能提供對應 Part A 的簡單 SDLC。所有路徑的共同底線進度記錄在PROGRESS.md狀態(tài)枚舉active | done | blocked見 packages/cli/src/lib/scope/progress-edit.ts證據(jù)一律經(jīng)rig proof add落盤、絕不手工放置切片在承諾的可觀察結(jié)果擁有證據(jù)之前不算完成最終以rig scope audit校驗。對一次 Bug 修復切片而言SOP 的落地順序通常為用 bug-fix 模板腳手架 → 替換占位、寫實 Repro/Expected/Actual 與證明契約 → 按 P 撥號選擇規(guī)劃嚴格度 → 修復過程中在PROGRESS.md記錄狀態(tài) → 用rig proof add提交復現(xiàn)消失或回歸測試命中的證據(jù) → 收尾時填寫PROOF.md→rig scope audit復核。八、與系統(tǒng)性調(diào)試技能的自然銜接bug-fix 模板的 Repro/Expected/Actual 結(jié)構(gòu)與 OpenRig 內(nèi)置的 skills/_canonical/process/systematic-debugging/SKILL.md 形成天然互補該技能的鐵律是先找根因再動手修癥狀修復就是失敗其 Phase 1 明確要求穩(wěn)定復現(xiàn)Reproduce Consistently、細讀錯誤信息、檢查近期變更、在多組件系統(tǒng)中逐層取證。這些恰好是模板中Repro、Expected、Actual、Impact四節(jié)要沉淀的內(nèi)容——模板負責把調(diào)試紀律固化成文檔結(jié)構(gòu)技能負責指導填出高質(zhì)量內(nèi)容。而模板 Proof contract 提示的repro 不再復現(xiàn) / 回歸測試釘住行為兩種證據(jù)形態(tài)也正是該技能 Phase 4修根因而非癥狀的可驗證外化。九、小結(jié)bug-fix 模板的完整閉環(huán)把全部環(huán)節(jié)串起來一次符合規(guī)范的 Bug 修復切片走的是這樣一條證據(jù)鏈rig scope slice create mission slug --template bug-fix生成SPEC.md含 frontmatter 點號 ID、Intent、Mini-requirements、Proof contract、Repro/Expected/Actual、Impact、Fix proposal并同步落盤slice.yaml、PROGRESS.md、PROOF.md、proof/用真實內(nèi)容替換全部方括號占位——占位會被 scaffold-placeholder.ts 識別不算作者內(nèi)容按 sdlc-conventions.md 的組件菜單選擇構(gòu)建路徑與 P0–P4 嚴格度在PROGRESS.md持續(xù)跟蹤用rig proof add以 C1 頭落盤證據(jù)--evidences回指證明契約條目、--media附帶proof/下媒體收尾填寫PROOF.mdrig scope audit最終校驗切片在證據(jù)齊備前不算 done。這套機制的獨特之處在于bug-fix 模板不是一張待填表格而是一條被渲染器、審計器、證明命令三方共同約束的契約——它讓修 Bug這件在傳統(tǒng)工程里最容易被口頭交代、事后無法追證的工作在 OpenRig 中獲得了與功能開發(fā)同等的結(jié)構(gòu)、證據(jù)與可審計性。贊分享人工智能AI Agent多智能體Agent 編排代碼智能體CLI【免費下載鏈接】openrigMulti-agent harness that runs Claude Code and Codex together as one system項目地址https://gitcode.com/GitHub_Trending/op/openrig點擊查看免費下載相關(guān)推薦OpenRig 技術(shù)債務(wù)治理實戰(zhàn)用 backlog-tech-debt Slice 模板把存量債變成可審計、可驗證的工作切片OpenRig 技術(shù)債務(wù)治理實戰(zhàn)用 backlog tech debt Slice 模板把存量債變成可審計、可驗證的工作切片 本文圍繞 OpenRig 倉庫中人工智能AI Agent多智能體Agent 編排代碼智能體CLI別再讓Issue被關(guān)閉用openJiuwen缺陷報告模板寫出快速被復現(xiàn)修復的Bug別再讓Issue被關(guān)閉用openJiuwen缺陷報告模板寫出快速被復現(xiàn)修復的Bug 提交過開源項目Issue的朋友可能都有過這樣的經(jīng)歷滿懷期待地報了一個BECC 缺陷修復編排指南用 /orch-fix-defect 實現(xiàn)紅測試驅(qū)動的 Bug 修復ECC 缺陷修復編排指南用 /orch fix defect 實現(xiàn)紅測試驅(qū)動的 Bug 修復 本文以 ECCThe agent harness perfor人工智能AI 技能AI 插件AI 評測Agent 評測MCP Clients開發(fā)工具創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考