engineering — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited engineering (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
這裡沒有關卡。派工怎麼切、實作怎麼做、試幾次、走哪條路，都在這裡，沒有人在等你交表格。 正因為頭尾兩個關卡在，中間才可以很隨便。
讀 {issue}/index.md 就夠了——凍結塊是成功的定義，可以改的那部分是其餘一切。不需要去翻別的 artifact。
bash .claude/skills/engineering/scripts/frozen-assertion-fence.sh verify {issue}/index.md
bash .claude/skills/driving-work-to-done/scripts/spine-loop-state.sh show --state {issue}/.spine/loop-state.json
bash .claude/skills/engineering/scripts/record-measurement-change.sh show --ledger {issue}/.spine/measurement-ledger.json第一次寫的命令要登錄 baseline：
bash .claude/skills/engineering/scripts/record-measurement-change.sh record \
--ledger {issue}/.spine/measurement-ledger.json \
--assertion-id A-P1 --new-command '<cmd>' --baseline量不到目標是常態，換就是了，但換要帶三元組：舊命令 hash、新命令 hash、以及這條新命令 在實作之前紅過的證據。
bash .claude/skills/engineering/scripts/record-measurement-change.sh record \
--ledger {issue}/.spine/measurement-ledger.json \
--assertion-id A-P1 --old-command '<舊>' --new-command '<新>' --red-evidence <path>紅不了的命令什麼都沒量。一個因為工具不存在而失敗的紀錄不算紅過，它只證明環境壞了。
量不到要說出來，不能回綠。 負向的量測天生會把「我沒看到」讀成「它沒發生」——掃到 0 個 檔案、找不到那棵樹、正則對上 0 次，這些在輸出上跟「掃過了，沒問題」長得一模一樣。所以每條 量測前面要有一個 preflight：目標在不在、樣本數夠不夠。preflight 不過就用另一個 exit code 停下來（慣例是 2＝量不到、1＝量到了而且是紅的、0＝綠），不要讓它走進判定。
自己剛寫的檢查第一次就綠是可疑訊號，通常代表規則太窄。落地之前先餵它一份已知壞掉的 輸入，確認它真的會紅。
| 發現的問題 | 怎麼辦 |
|---|---|
| 量測方法不對 | 原地改，帶紅過證據換命令，繼續 |
| 切分不對 | 重切，繼續 |
| assertion 不對 | 不是這一站能解的——回 driving-work-to-done 讀該停哪一種 |
施工計劃那一類不存在：這條流程不分「明確施工」與「嘗試實作」。看得懂就做，看不懂就先探。
一輪沒產出 code 也是一輪。「試過 A，撞到 X，結論走 B，code 全丟」是正常結果——這一輪的產出 是知識，寫進可以改的那部分就是交付。不要為了讓這一輪看起來有東西，把失敗的探索包裝成交付。
bash .claude/skills/driving-work-to-done/scripts/spine-loop-state.sh record \
--state {issue}/.spine/loop-state.json \
--outcome converged|unconverged|zero_delta --note '<一句話>'連續沒收斂到上限時流程升人類，不繼續自轉。上限是活區可調的參數，不是驗收條件。
方法自由，但有三件事 oracle 照不到，即使做了會變綠也要寫進可以改的那部分並講清楚為什麼，等人回話：
共同點是後果落在綠燈之外——測試會過，代價在別的地方。
還有一件不是這一站能處理的：
施工填下去就是在改成功的定義。
撞到的時候停 assertion_wrong，回 refinement，跟上面〈在這裡發現問題，先自己解〉表裡 「assertion 不對」那一列走同一條路。要推一個建議值，那是 refinement 簽 assertion 時的事：照 refinement〈交給 PM 與使用者的開發計畫〉把建議值列進待確認，這裡不抄第二份。
2026-10-21 的標本：需求原文只寫「先用建議門檻」，施工時填成一個百分位與一個天數。計畫沒回寫，也沒標 RD 提案，上到測試環境才被使用者問到。使用者原話：「你還沒確認門檻就做了嗎！」這一節隨後一度寫成 「施工填完、回寫待確認就繼續」，跟本站「凍結塊不要動」相反。使用者原話： 「我們 /driving-work-to-done 不是有定義 /engineering 不能改定義，要退回重新 /refinement 嗎」
可以改的那部分寫到讓下一個人（可能是明天的你）能接手：現在在哪、試過什麼、為什麼走這條、下一步是 什麼。凍結塊不要動——需要動它時，回 refinement，而且改完要 commit：凍結 ＝ commit， verify 會拿 fence 內文跟 git 歷史比，改了沒 commit 就是紅的，重簽也救不了。
這一輪做完，回 driving-work-to-done 讀下一步——換站與停點都由那裡回答，這一站不自己決定 往哪走。
check-your-own-work這一輪會開 PR、或往一顆已經開著的 PR 推新的改動時，開之前在改動落下去的那棵樹上跑一次 `check-your-own-work`，把它列出的每一項處置完。 怎麼指名那棵樹、為什麼要指名，在 swe-knowledge〈開 PR〉。
紀錄寫進單上可以改的那部分，一段，行首是 `check-your-own-work 九問`，後面帶跑在哪個 head 上，例如 check-your-own-work 九問，head a96b2f94 → 013ef5c3，接著逐問寫抓到什麼、 怎麼處置。行首這幾個字是給交付紀錄找的：verify-ac 寫交付紀錄時指向這一段，找不到就寫 「沒跑」。
這種輪次，那段紀錄存在才記成收斂。 沒有它就是還沒做完，不是做完了而少一份文件。
這一句放在這裡，是因為開 PR 的是這一站。2026-10-14 量到：同一個 epic 的九張子單只有兩張 跑過這一步，而那時候它只寫在 swe-knowledge 裡，這一站一個字都沒提。
你寫下的每一句描述性的話都是產出的一部分，不是旁白。 它對讀的人承諾了某件事，而承諾 與行為是分開演化的：先寫下承諾，做的過程中改了做法，然後沒有回頭改那句話。兩者從此各說 各話，而看起來完全正常——沒有東西會紅。
oracle 照不到這一類，因為量測量的是行為，不是描述行為的那句話。所以它只能自己讀一遍。 成本很低：送審前把這一輪寫過的描述掃過去，一句一句問「這句現在還是真的嗎」。
在描述裡承認一個邊界情況，就要追它到底——「這裡可能是空的」寫得出來，就要回答「那誰會 收到這個空的」。修掉眼前那個症狀不等於處理掉那個事實。
2026-08-07 的標本：外部審查開了五條意見，四條成立，而沒有一條是知識缺口，全部是同一 個形狀——我寫下的一句話跟我寫下的行為對不上。其中最嚴重的那條，我在同一個檔案裡就寫著 「這裡可能是空的」，只在其中一條路上處理掉，沒有跟著那個值往外追一步。
收到一條裁決，同一輪 grep 這張單（與它的母單）上所有引用同一件事的段落，改到一致。 commit 訊息列出改了哪幾段。裁決常常只落在一處，而單上依賴它的段落還寫著舊的說法；下一個 接手的人照那幾段做，做出來的是被推翻的那一版。使用者 2026-10-27 原話：「每張單的前因後果 應該都是清楚的，到底掉在哪」。那天一條裁決落在指揮官的紀錄裡，epic 上依賴它的三段沒有同一輪 改，新的線把其中一段照抄進對外的稿。
verify-ac 的交付紀錄會逐條檢查：fence 宣告的每個 assertion ID 都要有 verdict: PASS 的證據， 而且證據綁的 head 要等於要交付的那個 head。證據證的是一棵樹綠了，不是一條分支綠了； 量完之後又推了三個 commit，那些證據就跟要出去的東西無關了。
所以順序是：先追上 `origin/main` → code 全部 commit 完 → 才跑量測 → 才送審。反過來做， verify-ac 會把你打回來重量一次。
第一步最常被跳過，而它的代價跟其他幾步一樣大。 在一棵落後 origin/main 的樹上量完， 證據綁的是那棵舊樹；之後 rebase 上去，head 就換了，那批證據不再是要交付的那個 head 的 ——即使 rebase 前後的內容逐位元相同也一樣，交付紀錄比的是 head，不是內容。被打回來時 要重跑的是整趟量測，不是一條命令。
不要反過來去動那道檢查。 給它加一個「rebase 產生的 commit 免驗」的例外，等於讓每一份 證據都可能釘在別的樹上——而那件事沒有任何輸出看得出來。
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.