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