Set PII_DENYLIST org secret to activate the public-pii-gate reusable workflow

[saadqbal]

Summary

The Public PII gate caller workflow fails in 0 seconds with no jobs on every PR in every repo that adopted it, since 2026-06-17. The reusable workflow it references does not exist on `tracebloc/.github@main`.

Root cause

• The reusable workflow `.github/workflows/public-pii-gate.yml` exists only on branch `feat/public-pii-gate`, in open PR feat(security): public-repo PII gate (block customer names + secrets in PRs) #60 — which targets develop, and is unmerged.
• The per-repo callers reference it at `tracebloc/.github/.github/workflows/public-pii-gate.yml@main`.
• Because the file is absent on `main`, GitHub cannot resolve the reusable workflow → the run ends immediately as a startup failure (REST conclusion `failure`, 0 jobs). Example: cli run 27747191356 → `total_count: 0`.
• Note: `develop` is currently behind main by 10 / ahead by 0, so merging feat(security): public-repo PII gate (block customer names + secrets in PRs) #60 into develop would NOT fix this — callers consume `@main`. The file must land on main.

Ruled out: org reusable-workflow access policy (other `@main` callers such as `fr-gate` run green from these same public repos) and YAML syntax (file is valid; it simply isn't on main).

Security impact

This gate is meant to block PRs whose title/body/commits contain denylisted customer/partner names or known secrets on public repos. Because it errors out instead of running, PII scanning is non-operational on every adopting repo.

Affected repos (callers reference the missing `@main` workflow)

• `tracebloc/cli` — caller added by ci(security): add public-repo PII gate caller cli#81 (merged to develop 2026-06-17)
• `tracebloc/data-ingestors` — `.github/workflows/public-pii-gate-caller.yml`

Fix

1. Publish `public-pii-gate.yml` to `tracebloc/.github@main` (retarget/merge PR feat(security): public-repo PII gate (block customer names + secrets in PRs) #60 to main).
2. Confirm the gate runs green on a test PR in `tracebloc/cli`.

Follow-ups

• Verify the org Actions secret `PII_DENYLIST` is set (`--visibility all`). If unset, the gate runs but exits 0 as INACTIVE (warns, does not block) — PII protection still won't enforce. Requires org admin.
• Re-trigger the currently-red open PRs in cli so their check turns green.

Refs: PR #60 (tracebloc/.github), tracebloc/cli#81.

[saadqbal]

Diagnosis & status

Two stacked bugs, both root-caused:

Bug 1 — reusable workflow not on `main` (fixed). `public-pii-gate.yml` existed only on `feat/public-pii-gate` in open PR #60, which targeted develop (and `develop` is behind `main`, so merging there wouldn't have helped — callers consume `@main`). Retargeted PR #60 to `main` and merged it → file is now on `main`.

Bug 2 — token-permission escalation (fix verified, pending merge). Even with the file on `main`, every PR still hit a 0-job startup failure. Cause: the reusable workflow requested `permissions: { contents: read, pull-requests: read }`, but adopting repos run with `default_workflow_permissions: read` (grants `contents`/`packages` read, `pull-requests: none`). A minimal caller (`uses:` + `secrets: inherit`) can't grant `pull-requests`, so the called workflow's request exceeded the caller's ceiling → startup failure, no jobs. (Confirmed empirically: adding a matching `permissions:` block to a test caller turned it green; run 27748334189.)

Fix (PR #63)

Make the reusable workflow self-sufficient under the restrictive default so callers stay trivial:

• Read commit messages via the Compare API (`repos/{repo}/compare/{base}...{head}`, contents-scoped) instead of `gh pr view --json commits` (pull-requests-scoped).
• Request only `permissions: contents: read` (least privilege).

Verified green on a test PR in tracebloc/cli with an unmodified minimal caller pointed at the fix branch — jobs ran, no startup failure (run 27748465192). Full scan coverage (title + body + commit messages) preserved.

Remaining

1. PR fix(pii-gate): run under restrictive default token perms (contents-scoped Compare API) #63 needs one approving review from a non-author. The `main` branch is governed by an org ruleset (not visible via the classic protection API) that requires a PR + 1 review and does not honor admin bypass / self-approval / direct push. Once approved I'll squash-merge and re-verify on `main`. After that the gate is operational for cli + data-ingestors + every future adopter with zero caller changes.
2. Org secret `PII_DENYLIST` must be set (`gh secret set PII_DENYLIST --org tracebloc --visibility all --body "..."`). Until then the gate runs but exits 0 as INACTIVE (warns, doesn't block) — PII protection won't actually enforce. Couldn't verify its presence (needs `admin:org`).
3. Optional hygiene: `develop` in this repo is behind `main` and lacks the file entirely; sync if you rely on develop→main promotion.

Ruled out: org reusable-workflow access policy (sibling `@main` callers like `fr-gate` run green from the same repos) and YAML syntax (parses cleanly).

[saadqbal]

Rescoped (backlog grooming). The original headline fix shipped — public-pii-gate.yml is published to main and the token-perms/ref-missing 0s-fail is fixed (PR #63, merged 2026-06-18), so callers no longer fail on a missing ref.

Remaining work this ticket now tracks: the gate runs but is INACTIVE until the org secret PII_DENYLIST is set. That's the only outstanding item — retitled to reflect it.