Skip to content

reply 型第三方 verbatim payload 應強制 heightened scrub tier(不論 repo visibility)—— #269 DA-3 follow-up #272

Description

@kiki830621

Problem

idd-comment --type=reply#269,v2.100.0)是唯一逐字重製第三方原文的型別。其 egress 走既有 gh-egress choke-point,SCRUB_LEVELrepo visibility 決定(rules/privacy-scrubbing.md:third-party=enforce / own-public=warn / own-private=light)。

reply 的典型情境是「把第三方(reviewer / advisor)的逐字原文貼到使用者自己的 repo」——落在 warn / light(預設 proceed),永遠不會觸發 enforce 的 block-with-diff。加上機械 scrub net 抓不到 human-prose 私人內容(人名、未發表結果),實質只剩 LLM 語意自審一道 gate,而 reply 的 verbatim 強制正好對這道 gate 施壓(executor 傾向字面重現)。

#269 verify round 1 的 Devil's Advocate(DA-3, MEDIUM)指出:v2.100.0 已加的 R1 scrub-wins 優先序 clause + layer-3 heightened 自審 clause 是必要但不充分——沒有把 reply 的第三方 payload 拉到更強 tier,own-repo 情境仍靠預設放行。

Type

feature

Expected

評估並(若合理)實作:reply 型的第三方 verbatim payload(尤其 layer-3 使用者貼上的外部原文)在 egress 時強制套用至少 warn-with-explicit-confirm、或 enforce tier 的隱私 gate,不論 repo visibility。可能形態:

  • rules/privacy-scrubbing.md 的 tier resolution 增加一條「payload 含 reply verbatim 第三方 blockquote → tier 下限提升」規則;或
  • reply 專屬的 pre-egress 隱私 confirm step(own-repo 也要求人確認第三方逐字內容可上 remote)。

需權衡:own-private repo 對第三方逐字內容 block-with-diff 可能過重(使用者自己的私 repo)。故本案是設計決策,非機械修補——先評估比例原則再定形態。

Actual

v2.100.0 的 reply 只有 R1 的 prose clause(scrub 優先於 verbatim + layer-3 heightened 自審),tier 本身仍是 repo-visibility 預設;own-repo 情境的第三方 payload 靠 executor 自律,無機械強制。

Cross-ref


Current Status

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions