Private wiki gate: stderr output re-leaks canonical filenames

[marcusrbrown]

Context

PR #TBD added scripts/check-wiki-private-presence.ts and a workflow step in merge-data.yaml that blocks the promotion PR when private repo wiki pages exist. When a leak is detected, the script prints the matched filenames to stderr.

The filenames have the form owner--repo.md — they ARE the canonical names the privacy posture is supposed to keep out of public artifacts. Public workflow logs in GitHub Actions are visible to anyone who can read the repo, so the failure output re-leaks the information.

This was an explicit trade-off in the plan: 'the filename IS the leak so printing it to stderr is necessary for the operator to remediate.' But two reviewers (project-standards P1, adversarial P2) flagged it as inconsistent with the project's privacy posture.

Options

1. Redact to opaque identifiers + structured remediation. Print node_id, count, and a generic 'private wiki leak detected — see operator-only log' line. Operator runs scripts/resolve-private.ts (Unit 11) locally to map node_ids back to names. Cost: extra operator step; benefit: no public-log re-leak.
2. Print to a privileged log destination. Use GitHub Actions ::warning:: or ::add-mask:: annotations that aren't visible in the public log surface. Investigate which APIs preserve operator visibility while suppressing public surface.
3. Accept the trade-off explicitly. Document in metadata/README.md that the gate's failure output intentionally exposes canonical names because the leak has already happened (the file exists on data and is one merge away from being public). Add a comment in the script noting the trade-off and link to this issue.

Option 1 is the strongest privacy posture and lines up with Unit 11's design. Option 3 is honest but trades correctness for operational simplicity.

Acceptance

• Decision recorded in PR/commit message
• Implementation matches the chosen option
• If options 1 or 2: stderr output during failure contains no owner--repo strings
• If option 3: explicit doc + code comments

Surfaced by ce:review on feat/private-merge-data-wiki-block (round 1 P1 #4 and P2 finding #6).

[fro-bot]

Triage: this is already decided by the plan — implement Option 1.

The privacy plan (docs/plans/2026-05-05-002-feat-private-repo-handling-plan.md, KTD-6, line 170) is unambiguous:

Failure message: file path identified, name redacted via node_id reference, instruction to use scripts/resolve-private.ts to look up locally if needed.

That's Option 1 verbatim. The "filename IS the leak so we have to print it" trade-off recorded in the PR plan contradicts the document it derives from. Both reviewers (P1, P2) are right; the in-flight implementation drifted.

Why the other options don't survive contact with the architecture:

• Option 2 (::warning:: / ::add-mask::). ::add-mask:: only redacts the literal string in subsequent log lines — it doesn't help once owner--repo.md has already been emitted to stderr, and ::warning:: annotations are rendered into the public log surface too. There is no "operator-only log" tier in GitHub Actions on a public repo. This option doesn't exist the way it was described.
• Option 3 (accept the trade-off). The "the leak already happened on data" argument is true but irrelevant. origin/data being publicly readable is the constraint that forced always-redacted-everywhere in the first place (plan §0, line 16). The gate exists precisely to keep that leak from compounding into searchable, indexed CI log history attached to specific PR numbers and timestamps. Public logs are a different exposure surface than a redacted YAML blob on a branch — searchable by PR context, dated, attributable. Don't widen the surface because it's already non-zero.

Reproduction. scripts/check-wiki-private-presence.ts doesn't exist on main yet — this is a pre-merge defect on feat/private-merge-data-wiki-block. No reproduction needed beyond reading the diff; the issue body and reviewer findings already characterize the behavior precisely.

Next steps (for whoever lands the PR):

1. In scripts/check-wiki-private-presence.ts, on detection: emit count, file path (the directory, not the filename), and the matched entries' node_id values. No owner--repo strings to stderr or stdout.
2. Failure message ends with: run scripts/resolve-private.ts <node_id> to map locally.
3. Mirror Unit 10's hygiene from KTD-6: capture any gh api graphql output into shell vars, never echo; ensure ACTIONS_STEP_DEBUG stays off in the workflow.
4. Add a test asserting the stderr output contains zero -- separator patterns (regex \w+--\w+) when the gate fires.
5. Sibling issues Private wiki gate: defense-in-depth gaps (variants, subdirs, timeouts, non-repo wiki) #3327 (defense-in-depth: variants, subdirs, timeouts) and Private wiki gate: metadata-tampering bypass via flipping private→false in same PR #3328 (metadata-tampering bypass) should be addressed in the same PR or as immediate follow-ups — they're the same gate.

Acceptance criterion from the issue: "stderr output during failure contains no owner--repo strings". That's the test. Make it green.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/.github
Run ID	26142182086
Cache	hit
Session	ses_1bc437b4cffe1Nopd8hPixyU67

[marcusrbrown]

Tracked from PR #3329. Follow-up to the v1 private-wiki gate.