[FEATURE] Repo-aware privacy-scrubbing gate before gh issue create/comment

[kiki830621]

Problem / Motivation

When /idd-issue files to a third-party / public upstream repo (e.g. anthropics/claude-code), the issue or comment body can carry evidence gathered from the local machine — project directory names, absolute home paths, and collaborator names lifted from ~/.claude.json, transcripts, or diagnostic output. These are private and must not leak into a public tracker.

Today the operator has to remember to scrub this by hand every time. In the motivating session (diagnosing a Claude Code trust-dialog regression → contributing to anthropics/claude-code#71562) the scrub was manual and ad hoc: ~300 local project names had to be reduced to aggregate statistics before the comment was safe to post. That responsibility should not rest on human memory.

Proposed behavior

A pre-submit privacy gate that runs immediately before any outward dispatch — Step 3 gh issue create, Step 4 attachment upload, and the comment/edit paths of multi-finding mode.

The gate is repo-aware; its strictness is a function of the target repo:

Target repo class	Gate behavior
Public and third-party (owner ∉ my orgs, e.g. anthropics/*)	Enforce — scan drafted body + attachments for private-identifier patterns, show a redaction diff, require explicit confirm before dispatch
Public but own org (e.g. PsychQuant/*)	Warn — flag likely-private tokens, default proceed
Private repo	Light / off — audience already trusted (still honor the CLAUDE.md raw-third-party rule)

Where it hooks

• Extend the existing sanitize_source_label() machinery ([security] idd-issue multi-finding: dual-track sanitization design (IC_R007 verbatim vs GitHub body sanitization) #75) from filename/source-label sanitization to full body scanning.
• This is the natural extension of the operator's global CLAUDE.md "Git 隱私邊界" rule (raw third-party content never reaches a remote) — pushing that boundary from git commit out to the IDD issue/comment egress.

Type

feature

Expected

Before dispatching to a public/upstream repo, IDD detects candidate private identifiers in the drafted body, shows what it would redact, and blocks on confirmation — so a leak (e.g. a collaborator's name in a public bug report) cannot happen by forgetting to scrub.

Open questions

• Classifying "own vs third-party": git user's org memberships? an allowlist in issue-driven-dev.local.json?
• Redact-with-diff vs. block-until-edited.
• Private-identifier pattern set (home-dir absolute paths, ~/.claude.json project basenames, personal-name heuristics) — start conservative to avoid over-redaction.

---

Filed via /idd-issue (dogfooding). Motivating session: contributing population-level evidence to anthropics/claude-code#71562 required manually scrubbing 300 local project names down to aggregate stats before it was safe for a public tracker.

[kiki830621]

Diagnosis

Type

feature

Analysis (requirements breakdown)

Repo-aware privacy-scrubbing gate before any GitHub egress. Three requirements: (1) scan issue/comment bodies for private identifiers — home paths (/Users/<name>, $HOME, ~/), ~/.claude.json project basenames, personal names — before dispatch; (2) repo-aware strictness (public+third-party → enforce block+confirm; public+own-org → warn; private → light); (3) cover all egress points, not just multi-finding.

Existing building blocks:

• sanitize_source_label() — skills/idd-issue/SKILL.md:1815-1865 ([security] idd-issue multi-finding: dual-track sanitization design (IC_R007 verbatim vs GitHub body sanitization) #75). Control-char + bidi + mention-refuse filter, skill-local, multi-finding-only. Does NOT cover home-path / project-basename / personal-name.
• Repo classification already exists — references/config-protocol.md:238-268 (feature: 偵測「clone 他人 repo」情境並建議非污染式 IDD setup（config 擺放 + .git/info/exclude） #192/feat: third-party clone setup — detection + non-polluting config placement (#192) #197). Classifies push-permission (own vs third-party via viewerPermission), NOT isPrivate visibility, NOT a PII allowlist. Already carries a "public-visibility warning" (:258) — the closest existing hook.
• ~12 egress sites run gh issue create/comment/edit across idd-issue/comment/edit/diagnose/implement/plan/update/clarify/close/verify/all-chain; only the multi-finding path sanitizes today.

Impact

• New rules/privacy-scrubbing.md + a references/-level shared contract (the current helper is trapped inside one SKILL.md).
• Extend config-protocol.md classification to read actual repo visibility (isPrivate) on top of existing own/third-party.
• Config schema: add a privacy allowlist field.
• Retrofit ~12 egress sites to route bodies through the shared gate.
• openspec: no spec governs body-content scrubbing ([security] idd-issue multi-finding: dual-track sanitization design (IC_R007 verbatim vs GitHub body sanitization) #75 never lifted). New capability spec + touches idd-issue-multi-finding-source + add-third-party-clone-setup.

Strategy

• Lift + generalize sanitize into a shared privacy-scrub helper (not skill-local) — done: rules/privacy-scrubbing.md + scripts/gh-egress.sh (shared home; sanitize_source_label untouched per D5)
• Extend repo classification to read actual isPrivate visibility atop existing own/third-party — done (config-protocol.md, 3-level)
• [-] Define a conservative private-identifier pattern set (home paths, ~/.claude.json basenames, name heuristics) — won't fix: design pivoted to LLM semantic detection in discuss (D1); no maintained pattern set. Wrapper keeps only 2 mechanical zero-tolerance literals.
• [~] Repo-aware gate policy (enforce / warn / light) hooked at all egress sites — partial: Phase 1 lands idd-issue (10 sites); other 11 sites deferred to Phase 2 (tasks.md §5)
• Add rules/privacy-scrubbing.md + an openspec capability spec — done

Conflict Class

C_shared_module_coord — touches the cross-skill sanitize/egress machinery (sanitize_source_label + ~12 gh-dispatch sites) and the shared config-protocol repo-classification contract. Changes must coordinate across many skill files + the classification reference; not parallel-safe.

Complexity

Spectra

• Layer 2 (necessary): introduces a shared privacy-scrub helper + rule consumed by ~12 egress skills — a published cross-skill surface whose behavior contract should be a documented spec.
• Layer 3 signals (all three): (a) modifies normative behavior of the idd-issue-multi-finding-source dispatch spec; (b) cross-spec impact — coordinates config-protocol classification + add-third-party-clone-setup + a new privacy capability; (c) architectural decision with long-term maintenance implications (classification model, redact-vs-block, pattern set inherited by every egress site).
• Repo is a live openspec/Spectra shop → routes through spectra-discuss → propose → apply.

Risks

• Over-redaction (false positives) — pattern set must start conservative.
• Personal-name detection is inherently heuristic — highest false-positive risk; likely needs allowlist/denylist rather than pure pattern.
• Visibility proxy: existing classification uses push-permission, not isPrivate — conflating them mis-gates.
• 12-site retrofit = wide blast radius; needs a shared hook to avoid per-skill drift.

Residue

The "own vs third-party" split is a mechanical proxy for the real intent ("is this audience trusted with my local identifiers") — the same residue already flagged in add-third-party-clone-setup/design.md:145. The gate reduces but cannot fully operationalize "what counts as private to me"; personal-name detection especially remains judgment, not rule.

Vagueness Pre-check

• V1 (vague WHAT): 3 — WHAT is clear (privacy gate before egress); the open items are HOW/design (classification mechanism, redact-vs-block, pattern set), not WHAT.
• V4 (vague ACCEPTANCE): 3 — Expected is stated (detect → show diff → block on confirm), but crisp acceptance (which patterns count, over-redaction tolerance) is left to design.
• Triggered: no — both axes ≤ 3. [Unattended mode: would auto-proceed regardless.]

---

🤖 Diagnosis via /idd-all (unattended). Routed: Spectra → spectra-discuss.

[kiki830621]

Closing Summary

Problem

IDD's ~12 GitHub egress sites (gh issue create/comment/edit) dispatched AI-drafted bodies with no privacy gate. On public/third-party repos, drafts could irreversibly leak local/private identifiers — home paths (/Users/<name>), ~/.claude.json project basenames, collaborator real names — into a public tracker.

Root Cause (feature motivation)

The only existing defense, sanitize_source_label (#75), was skill-local (trapped in idd-issue), multi-finding-only, and a character/mention hygiene filter — not a semantic private-identifier scan, and covering none of the other 11 egress sites.

Solution

Spectra change add-privacy-scrubbing-gate (Phase 1). Design (owner-approved via discuss):

• Detection = LLM semantic self-review, not a fixed regex/denylist (D1 — grounded in the repo's own .claude/rules/attribute-assessment.md: "honest AI judgment > deterministic match on a wrong feature"). Personal-name detection is LLM judgment; no maintained pattern set.
• Enforcement = minimal deterministic checkpoint: single choke-point wrapper scripts/gh-egress.sh guarantees the self-review ran (via --scrub-attested <level>, value = resolved repo-visibility strictness — unproducible without running classification) + a 2-item mechanical net for zero-tolerance literals. No semantic matching in the wrapper.
• Classification: reuse viewerPermission own/third-party + new isPrivate query → 3 levels (third-party ENFORCE / own-public WARN / private LIGHT).
• ENFORCE = block-with-diff, never silent auto-redact; shared home = rules/privacy-scrubbing.md + wrapper, sanitize_source_label untouched.
• Phasing: Phase 1 lands idd-issue (10 live egress sites); the other 11 sites deferred to Phase 2 (tasks.md §5).

Verification

Two independent adversarial AI reviewers — both PASS, zero blocking:

• design/spec conformance: attestation wiring correct + fails closed; sanitize_source_label byte-identical; all 8 spec requirements have artifacts; §5 correctly deferred.
• wrapper security: attestation enforcement airtight (11 break-probes, none bypass exec gh); passthrough byte-identical.
• gh-egress suite 19/19; full repo suite 10/10; openspec validate --strict valid.
• Merged via PR Privacy-scrubbing gate Phase 1 — LLM-detect + deterministic choke-point wrapper (idd-issue) #204 (squash).

Changes

• 7691566 openspec change add-privacy-scrubbing-gate
• dbcc236 wrapper + rule + tests
• 565cf6d isPrivate classification
• 1c072dc idd-issue egress retrofit (Phase 1)
• f792019 Q1 attestation resolution + Phase 1 tasks
• 26908e4 release v2.87.0
• PR Privacy-scrubbing gate Phase 1 — LLM-detect + deterministic choke-point wrapper (idd-issue) #204 (merged)

Residue Acknowledgement

Diagnosis declared: "own vs third-party is a mechanical proxy … personal-name detection especially remains judgment, not rule." Acknowledged as still residue: the visibility-proxy half is resolved (new isPrivate query splits own-public vs own-private, per D3), but "what counts as private / personal-name judgment" is permanently an LLM-semantic residue — the intended consequence of D1. Not an actionable bug; no follow-up filed.

Follow-ups

• [FOLLOWUP #202] Privacy-gate mechanical-net precision + wrapper hardening #203 — mechanical-net precision + wrapper hardening (6 non-blocking; idd-all: 增加 HITL（attended）模式 — direct-commit + 允許 sub-skill AskUserQuestion #1-2 recommended before Phase 2 rollout)
• Phase 2 (other 11 egress sites) — tracked in add-privacy-scrubbing-gate/tasks.md §5

Distribution Sync

• Detected: plugin (issue-driven-dev)
• Choice: skip — hold until [FOLLOWUP #202] Privacy-gate mechanical-net precision + wrapper hardening #203 finding idd-all: 增加 HITL（attended）模式 — direct-commit + 允許 sub-skill AskUserQuestion #1 (over-broad .claude.json net) is fixed + Phase 2 lands
• Manual when ready: /plugin-tools:plugin-update issue-driven-dev
• At: 2026-07-01T14:00:09Z