idd-issue multi-finding：run log 的 finding_quote 預設逐字並 commit 進 git，和 privacy gate「第三方逐字內容不進 remote」衝突 (sibling concern from #420) #421

Activity

1. kiki830621

   added

   bugSomething isn't workingSomething isn't working

   on Oct 24, 2026
2. kiki830621 commented on Oct 26, 2026

   

   kiki830621

   on Oct 26, 2026 – with Claude

   MemberAuthor

   More actions

   Diagnosis

   Type

   bug

   Root Cause / Analysis

   我認為 root cause 是這樣：multi-finding run log 的兩條規定（逐字、預設 commit）是在只考慮終端機安全和跨機器延續時寫下的；privacy-scrubbing 規則則刻意只管 gh issue 的 body。結果 git commit 這條路上沒有任何閘，也沒有任何一處寫明兩條規則衝突時哪條優先。證據如下：

   1. 逐字是 SHALL。 skills/idd-issue/SKILL.md:1475：

      finding_quote: verbatim original text(no AI rewording — 同 IC_R007 source-preservation 紀律)

      同一條規定也出現在 schema（:2085 finding_quote: string; // verbatim from source）、:2130（jsonl actions[].finding_quote MUST contain the verbatim source content），以及 spec openspec/specs/idd-issue-multi-finding-source/spec.md:90-104（Scenario: Verbatim quote preserved）。

   2. commit 是預設。 SKILL.md:2062：

      Commit 進 git(不 gitignore),確保 cross-machine continuity。

      同一份 spec 的 :416-425 寫「JSONL run log SHALL be committed to git by default」。

   3. Stage 4.5 只看檔案有沒有被 ignore。 SKILL.md:1662-1830 唯一的判斷是 git check-ignore -v（:1769）。沒被 ignore 就走到 :1819 的 JSONL_GITIGNORE_DECISION="committed" # not ignored, silent pass。不 commit 的情況只有四種：路徑被 ignore、選 Abort、設環境變數略過、unattended（:1644-1660 自動選 skip-commit）。有人在場的一般路徑上，完全沒有提示。

   4. [security] idd-issue multi-finding: dual-track sanitization design (IC_R007 verbatim vs GitHub body sanitization) #75 的 dual-track 只處理顯示安全，不處理隱私。 SKILL.md:2116-2134 把 jsonl 定為逐字的 source of truth，GitHub body 改用 finding_quote_display；sanitize 的是控制字元和 bidi 字元。:2064 的 CAUTION banner 也只談終端機。

   5. 隱私規則在 LIGHT 仍要擋第三方逐字，但範圍只限 body。

      • rules/privacy-scrubbing.md:80 的 LIGHT 列寫「still honor ... raw third-party verbatim content does not go to remote」；skills/idd-issue/SKILL.md:335 是同一個意思。
      • 這條的 spec 只存在於還沒封存的 change：openspec/changes/add-privacy-scrubbing-gate/specs/privacy-scrubbing-gate/spec.md:91-95。
      • 同一份規則在 :27-29 把範圍限定在 body：

        This is the same privacy boundary as the global CLAUDE.md rule "third-party verbatim content does not go to remote" — only here the leak path is the AI-drafted issue/comment body, not a raw file.

      • 實作契約 :149-167 列的 egress site 也只有 gh issue create/comment/edit。

      所以 GitHub body 那一側，有 Stage 4 的 LLM 自審可以仲裁：2026-10-24 那次 issue 正文只寫時間定位，就是在這裡做的判斷。git 那一側什麼都沒有，只能靠 agent 自己偏離 schema，而 schema 又沒有欄位能標出這筆偏離了。

   6. repo 裡已有「隱私優先於逐字」的先例。 skills/idd-comment/SKILL.md:417（reply 的 R1）：

      但 verbatim 服從 privacy-scrub gate …… scrub 優先於 verbatim（衝突時 redaction 勝）

      multi-finding 沒有對應的句子。

   7. 更廣的設計缺口已經有 issue。 feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 指出：內容進 repo 的路徑（commit、檔案、push）沒有隱私閘。本 issue 是它的一個具體實例。

   目前沒有程式讀 run log：grep issue-runs 只命中 SKILL、spec 和 gitignore helper 的測試。所以 schema 改了，目前沒有程式會受影響；會讀它的是人，以及 crash-recovery 流程（:1635-1642 用 comment_url grep jsonl）。

   Existing work

   (none)

   Impact

   • 影響的檔案：
     • plugins/issue-driven-dev/skills/idd-issue/SKILL.md（Stage 1、Stage 3 preview、Stage 4.5、JSONL schema、Content sanitization contract）
     • plugins/issue-driven-dev/rules/privacy-scrubbing.md
     • openspec/specs/idd-issue-multi-finding-source/spec.md
     • privacy-scrubbing-gate 的 spec（目前在 openspec/changes/add-privacy-scrubbing-gate/）
     • plugins/issue-driven-dev/references/usecase-routing.md:72
     • 新的測試
   • 影響的使用者流程：multi-finding mode 用第三方來源（聊天紀錄、逐字稿、信件），跑 Stage 4 → 4.5 → 寫出 jsonl。任何可見度的 repo 都受影響；private 的 LIGHT 只是最不容易察覺的情況，公開 repo 更嚴重。

   Strategy

   • 在 /spectra-discuss 定下做法和優先序（候選做法見 Risks 第一項，問題已交給維護者）。
   • 先寫測試（RED）：新增 drift-guard scripts/tests/multi-finding-privacy/test.sh，用跟 scripts/tests/idd-comment-reply/test.sh 一樣的內容斷言形式，檢查：
     • schema 有 quote_kind（verbatim|locator，沒寫就是 verbatim）和 locator 欄位
     • Stage 1 明文寫出「第三方來源 → locator，隱私優先於逐字」
     • Stage 4.5 在寫出 jsonl 前有隱私分支，committed 路徑上不會出現第三方逐字
     • rules/privacy-scrubbing.md 點名 run log 的 commit 通道
   • 改 spec（Spectra change）：MODIFIED「Stage 1 Extract SHALL produce paragraph-level findings with original quotes」和「JSONL run log SHALL be committed to git by default」兩條，並和 privacy-scrubbing-gate 的 LIGHT 情境對齊。做法是先封存 add-privacy-scrubbing-gate，或在同一個 change 裡處理它懸空的 delta。
   • skills/idd-issue/SKILL.md Stage 1：每個 finding 由 LLM 判斷是不是第三方（依 attribute-assessment，不用關鍵字比對），Stage 3 batch preview 多一欄，可以逐列改。
   • schema（:2083-2098）加 quote_kind 和 locator（來源、時間或位置、說話者角色）；Stage 4.5 寫出 jsonl 的步驟依選定的做法改，例如 committed 的 jsonl 寫 locator，逐字寫到另一個用 scripts/git-ignore-block.sh --direction exclude 擋下的檔案。
   • 同步 :2064 的 CAUTION banner 和 :2112-2134 的 dual-track 段落，順便修正已經失效的「IC_R007 line 1007」行號（第 1007 行現在是 Step 3.5 的 label 說明）。Stage 4 組 body 也依同一個 quote_kind：只是把 gate 本來就在做的判斷寫明，不新增行為。
   • rules/privacy-scrubbing.md:27-29 補一句：IDD 自己寫進 repo 的產物（run log）同樣受 LIGHT 的第三方逐字條款約束，並指向 feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395。
   • 同步 references/usecase-routing.md:72（那裡寫「commit 進 git」），更新 CHANGELOG 與版本。

   Conflict Class

   C_shared_module_coord
   共享資源有兩個：

   • openspec/specs/idd-issue-multi-finding-source/spec.md：idd-issue／idd-comment：附件可以只用 repo 相對路徑指向本機檔，不上傳 attachments release #420 改它 :390 的附件條款，未封存的 add-privacy-scrubbing-gate 另有一份還沒套用的 MODIFIED delta。
   • skills/idd-issue/SKILL.md：idd-issue／idd-comment：附件可以只用 repo 相對路徑指向本機檔，不上傳 attachments release #420、idd-issue／idd-comment：Telegram 附件改用 download_message_media 下載；idd-comment 補附件保留規則 #415 改同一個檔案的 Step 1／4。

   要和這兩邊排定順序。

   Complexity

   Spectra — Layer 2：run log 的 schema 是 published plugin skill（idd-issue multi-finding mode）文件化的輸出契約，讀者要看 spec 才知道 finding_quote 是逐字還是 locator；issue 的 Expected 要求的正是讓 schema 能標出這點。Layer 3：要改既有 published spec 的兩條 SHALL（idd-issue-multi-finding-source 的 spec.md:90-104 逐字、:416-425 預設 commit），還要和第二份 spec（privacy-scrubbing-gate 的 LIGHT 情境）保持一致。Layer 1 沒有命中；Layer V 沒有觸發。
   Hard-gate: triggered — 同一個概念散在 ≥5 個檔案：skills/idd-issue/SKILL.md（Stage 1／3／4.5、schema、sanitization contract）、openspec/specs/idd-issue-multi-finding-source/spec.md、privacy-scrubbing-gate 的 spec、rules/privacy-scrubbing.md、references/usecase-routing.md，加上新的測試。Spectra 已經先成立。

   Risks

   • 做法的選項（由維護者決定）：
     • (A) commit 進 git 的 run log 對第三方 finding 寫 locator，逐字另存到一個 gitignore 擋下的檔案。這樣保留了跨機器延續（D2 的理由），也和 reply 的先例一致。
     • (B) 只要有第三方 finding，整份 run log 預設 skip-commit。最簡單，但那一次 run 就沒有跨機器延續。
     • (C) 只留 locator，IDD 不另存逐字。jsonl 就失去「還原來源說了什麼」的功能（:2134）。
   • 「是不是第三方」是 LLM 的判斷，兩個方向判錯的後果不對稱：把第三方誤判成使用者本人，逐字就進了 git，收不回來。主要防線是讓人在 Stage 3 preview 逐列確認。
   • 跟 feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 的關係：如果 feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 之後做出通用的 repo 內容隱私閘，run log 應該成為它的一個使用者，而不是另一套規則。本 issue 先點修時，不要寫出跟 feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 衝突的分級。
   • 未封存的 add-privacy-scrubbing-gate change：tasks 5.x 沒勾、spec 不在 openspec/specs/、對 multi-finding spec 的 delta 也沒套用。本 change 的 spec 修改會撞上那份懸空的 delta，要先處理它。
   • 已經 commit 的舊 run log：既有 repo 的歷史裡可能已經有含第三方逐字的 jsonl。本修正只改之後的行為；歷史要重寫還是不動，需要另外討論。
   • 跟 idd-issue／idd-comment：附件可以只用 repo 相對路徑指向本機檔，不上傳 attachments release #420（同一個 session 發現的 sibling）不建議合成一個 change：兩者動的程式路徑、測試、待決問題都不同，共用的只有 skills/idd-issue/SKILL.md（不同段落）和 multi-finding spec（不同條款），分開做、依序合併即可。做法 (A) 的逐字旁檔放哪，可以和 idd-issue／idd-comment：附件可以只用 repo 相對路徑指向本機檔，不上傳 attachments release #420 討論「只留本機的東西放哪」時一起定。
   • 版本號：PR feat: run /idd-all in Claude Code cloud sessions — REST egress and reads, (PR, attended) — 3.6.0 (#416) #426 和 feat: 討論中持續更新 issue：問題變了改正文、診斷變了改 Diagnosis 留言、補充才新增 comment #424 都升到 3.6.0。

   Residue

   IC_R007 讓 jsonl 能還原「來源字面上說了什麼」（:2134 的 forensic 用途）。第三方 finding 改寫成 locator 之後，只有本機還留著來源檔或旁檔時才做得到；對 git 歷史來說，這部分意圖保留不了。

   Open questions（交給 /spectra-discuss）

   • Which resolution for third-party finding_quote in the run log? (A) committed jsonl carries a locator (source, time/position, speaker role) for third-party findings and the verbatim goes to a gitignored sidecar next to it — keeps D2 cross-machine continuity, matches the reply-type 'redaction wins over verbatim' precedent at skills/idd-comment/SKILL.md:417 (recommended); (B) the whole run log defaults to skip-commit whenever any finding is third-party — simplest, loses continuity for that run; (C) locator only, IDD persists no verbatim copy — jsonl loses its forensic 'what did the source say' role.
   • Handle idd-issue multi-finding：run log 的 finding_quote 預設逐字並 commit 進 git，和 privacy gate「第三方逐字內容不進 remote」衝突 (sibling concern from #420) #421 now as a point change, or fold it into feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 (repo-content privacy gate design)? Recommend: do the point change now and reference feat: privacy needs its own design in IDD — a gate for content that goes into a repo (commits, files, pushes) and a dedicated TaskCreate step #395 so its eventual gate treats the run log as one consumer.
   • Who classifies a finding as third-party? Options: (a) LLM per-finding judgment shown as a column in the Stage 3 batch preview with per-row override (recommended); (b) one per-run question to the user.
   • Existing run logs already committed with third-party verbatim in some repos' history: leave them, or provide a rewrite/cleanup path? (out of the fix itself; needs a maintainer call)

   Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

   • idd-plan／idd-clarify／idd-close／idd-all-chain 仍用 raw gh issue 寫入，繞過 gh-egress 隱私閘與空 body 防護 (sister concern from #421) #427 — idd-plan／idd-clarify／idd-close／idd-all-chain 仍用 raw gh issue 寫入，繞過 gh-egress 隱私閘與空 body 防護
   • openspec change add-privacy-scrubbing-gate 未封存：privacy-scrubbing-gate spec 不在 openspec/specs、Phase 2 task 未勾 (sister concern from #421) #433 — openspec change add-privacy-scrubbing-gate 未封存：privacy-scrubbing-gate spec 不在 openspec/specs、Phase 2 task 未勾

   Source: surfaced during /idd-diagnose #421 sister concern surfacing (Step 3.6)

   Vagueness Pre-check

   • V1: 2 — 互相衝突的兩條規則和位置都點名了（Stage 1 逐字、D2 預設 commit、Step 0.6 的 LIGHT），Expected 要求「明定其中一種做法」並列出候選；選哪一種是 Layer P 管的 HOW，不影響要做什麼。
   • V4: 2 — 完成條件可以檢查：skill 明文寫出優先序、schema 能標出 locator、預設路徑不再把第三方原話 commit 進 git。
   • Triggered: no — both axes ≤ 3

   ---

   Generated by Claude Code