swiftify 的 `--paragraphs-only` 在兩個使用者入口都不可見 — SKILL.md 仍寫「達不到」，預設 word reverse 零提示

[kiki830621]

Problem

#176 修好了 CLI 端：--coverage 現在會在根因是 paragraph-no-paraId 時說出根因並指出 --paragraphs-only。但它的 closing summary 自己把剩下的部分列為唯一未兌現的 Strategy 項，且明說沒開新案：

未做：swiftify SKILL.md 的 trade-off 表，以及「達不到人類可讀的 Swift」一句的前提補正。SKILL.md 住在 plugins/macdoc/skills/swiftify/，屬 plugin 發布物，改它要走 plugin 版本流程。這是本張唯一未兌現的 Strategy 項——CLI 端已會說出替代路徑，但文件端仍會把讀者導向錯誤結論。
— 來源：#176 closing summary，「未兌現的 Strategy 項與 Residue」段

那個預測在今天實現了，而且踩到的是一個載入了該 skill 的 AI agent。

在一個教學 repo 要處理一份 Word 2010 產生、零 w14:paraId 的 .docx 時，流程是：跑 --coverage 看到 Aggregate: 0.0% DSL → 讀 swiftify/SKILL.md → 讀到下面這句 → 判定 swiftify 不可用 → 對使用者回報「swiftify 對這份檔案結構上不適用」並改用另一套工具鏈（docx npm）重建文件：

如果你的目的是「產生人類可讀的 Swift 文件原始碼」，raw channel 的文件達不到，而且這不是設定問題——需要 ooxml-swift 支援 rich table 的 typed 表示與 sub-part 局部降級，兩者目前都不存在。
— 來源：plugins/macdoc/skills/swiftify/SKILL.md:144

--paragraphs-only 是後來才因為 CLI 順手把它印在 --coverage 輸出裡才被發現的。skill 全文 grep paragraphs-only 零命中。

這不只是文件過時。今天另外測到 #176 的修正沒有涵蓋的第二個缺口。

Type

bug

Expected

使用者實際會碰到的兩個介面，至少要有一個講出 --paragraphs-only 這條路：

1. swiftify/SKILL.md —— 補上 --paragraphs-only 與其代價（可讀 DSL + slot 可用，但重播只保證 content-equivalent、不再 byte-equal），並修正 :144 那句的前提。該句目前對 paragraph-no-paraId 這一類文件是錯的（對 table 那一類仍然正確），而它現在的寫法沒有區分這兩類。
2. word reverse 的預設路徑（不帶 --coverage） —— 落 raw 且根因是 paragraph-no-paraId 時，應該至少印一行 stderr 提示。條件化紀律沿用 第三方 Word 文件零 w14:paraId 時 swiftify 無可用產出，且沒有補救路徑（DSL 與 slot 同時失效） #176 已定的那條：只對 paragraph-no-paraId 發，table / byte-mismatch / parse-error / sibling-part 不發（它們沒有這條替代路徑）。

Actual

(a) SKILL.md 完全沒提 --paragraphs-only

$ grep -c "paragraphs-only" plugins/macdoc/skills/swiftify/SKILL.md
0

:144 仍在，且「這不是設定問題」這半句會主動勸阻讀者去找旗標。

(b) 不帶 --coverage 的預設路徑零提示（#176 的修正掛在 reportCoverage，預設路徑沒經過它）

同一份零-paraId 檔案，兩條路徑對照：

# 使用者最可能打的指令 —— 沒有任何異常訊號
$ macdoc word reverse <零-paraId>.docx --to-mdocx out.mdocx.swift
已寫入: out.mdocx.swift
$ echo $?
0
$ wc -l out.mdocx.swift          # 22 行
$ awk '{if(length($0)>m)m=length($0)}END{print m}' out.mdocx.swift
27239                            # 最長一行 27,239 字元的 escape XML

# 要「知道去按」這個旗標，才拿得到根因與補救路徑
$ macdoc word reverse <零-paraId>.docx --to-mdocx out.mdocx.swift --coverage
...
note: word/document.xml 落 raw 的根因是 paragraph-no-paraId ...
        · --paragraphs-only ：可讀的 DSL、--slot 可用 ...

而 --paragraphs-only 對同一份檔案確實有效（重現 #176 errata 的結論）：

$ macdoc word reverse <零-paraId>.docx --to-mdocx out2.mdocx.swift --paragraphs-only
$ wc -l out2.mdocx.swift         # 83 行
$ awk '{if(length($0)>m)m=length($0)}END{print m}' out2.mdocx.swift
267                              # 最長行 267 字元
$ head -8 out2.mdocx.swift
import WordDSLSwift

let document = WordDocument {
    Section(id: "main") {
        Paragraph(id: "p1") {
            "Assignment 02"
        }

Impact

補救路徑存在，但在兩個入口都看不到，等於對不知道它的人不存在。

失效方式是安靜的：預設指令 exit 0、印「已寫入」、產出一個通過 byte-equal 驗證的檔案。沒有任何訊號說「這份產物除了封存之外沒有用途，而且有一條你可以走的替代路」。使用者唯一會收到的負面訊號是 --coverage 的 0.0% DSL，而 SKILL.md 正好把那個數字解讀成「沒救」。

證據強度：這條路徑已經被走過一次（#176 的原始 body 就是這樣開出來的，前提錯誤），修完 CLI 之後今天又被走了一次——這次錯誤結論還被回報給了使用者、並導致改用另一套工具鏈。同一個誤導在同一份文件上重現兩次，第二次發生在「CLI 已經修好」之後，說明 CLI 端的修正不足以攔截它。

已知範圍界線

• 這張不是 macdoc word normalize --add-paraids。那個是 第三方 Word 文件零 w14:paraId 時 swiftify 無可用產出，且沒有補救路徑（DSL 與 slot 同時失效） #176 明列的另一項 residue（設計決定，讓文件取得真 paraId 以同時拿到 DSL + slot + byte-equal），與本張的「把既有替代路徑講出來」是不同性質、不同成本的工作。
• 這張不重開 第三方 Word 文件零 w14:paraId 時 swiftify 無可用產出，且沒有補救路徑（DSL 與 slot 同時失效） #176。第三方 Word 文件零 w14:paraId 時 swiftify 無可用產出，且沒有補救路徑（DSL 與 slot 同時失效） #176 的 CLI 修正有效且已驗證；本張處理的是它自己聲明未做的文件項，外加一個當時未涵蓋的預設路徑缺口。
• SKILL.md 屬 plugin 發布物，修它要走 plugin 版本流程（第三方 Word 文件零 w14:paraId 時 swiftify 無可用產出，且沒有補救路徑（DSL 與 slot 同時失效） #176 closing summary 已指出這一點）。(a) 與 (b) 可以分開落地。