GitGuardian flags a synthetic JWT in #145's branch history

[lamemustafa]

Blocks #145's checks. Needs a dashboard action on the maintainer's GitGuardian account — it cannot
be fixed from the repository.

What happened

While closing a P1 about credential-shaped values reaching the tidy CSV, I added a test fixture
containing a JWT-shaped string. GitGuardian flagged it: 1 secret uncovered!

The value is synthetic — an HS256 header, a {"sub":"synthetic"} payload, and the literal text
synthetic-signature as its signature. It was never a credential and grants nothing.

Why the fix did not clear the check

648c2fb removes the literal: the token is now assembled at runtime from encoded parts, so no
JWT-shaped string exists in source. grep -c "eyJ" over the test file returns 0, and the test still
fails without the guard it exercises.

The check still fails, because GitGuardian scans every commit in the pull request — its own
summary says "the scan of 73 commits" — and the literal remains in 19b9bbf, where it was
introduced. A later commit cannot remove it from history.

Why I did not rewrite history

AGENTS.md forbids amending or rebasing a pushed commit, without exception. Doing it to quiet a
scanner finding would be the wrong trade even if it were allowed: the finding is a true positive
about what is in the branch, and the branch does contain it.

What resolves it

1. Dismiss the finding in GitGuardian as a test fixture. This is the honest disposition — the
   value is synthetic and 648c2fb has already removed the pattern from source, so the finding
   cannot recur.
2. Merging feat(summary): add full-year workbook #145 as a squash puts only the combined tree on master, which contains no literal.
   The PR check will keep failing until (1) is done.

Worth keeping

Verified before assuming: GitGuardian passed on the commit immediately before mine and failed on
mine, so the trigger is unambiguous, and no other secret is implicated.

The general lesson is narrower than "avoid JWTs in tests": a scanner cannot tell a synthetic token
from a real one by looking at it, so a synthetic one costs a human triage every time. Assembling such
values at runtime — as 648c2fb now does — keeps the test honest and the scanner quiet.

[lamemustafa]

The repository-side blocker this issue exists for is gone. Whether the issue closes depends on one thing I cannot see.

Evidence from the repository:

• feat(summary): add full-year workbook #145 is merged, and its branch tapish-codex/summary-sheet has no remaining refs on origin — so the branch history GitGuardian scanned is no longer reachable from a live branch.
• GitGuardian Security Checks reports SUCCESS on the last four merged PRs (docs(store): correct the listing to the published beta and GSTR-2B scope #192, feat(gst): add GSTR-2B invoice workbook #196, fix(gst): normalise JSON number tokens before judging them #198, feat(gst): add an ITC summary sheet and a reconciliation key to the GSTR-2B workbook #199). It has not blocked anything since.
• The only eyJ match left in the tree is the detector itself — the JWT_SHAPE regex in filed-returns-summary-sheet.ts that the original fixture was written to exercise. That is a pattern, not a credential, and GitGuardian does not flag it.

So the stated purpose — "Blocks #145's checks" — is resolved: nothing is blocked, and the check has been green for every PR since.

What I cannot verify. This issue says explicitly that it needs a dashboard action on your GitGuardian account and cannot be fixed from the repository. Whether that incident is still open there is not observable from here, and a green check on new PRs does not prove an old incident was dismissed — it only proves no new secret is detected.

Recommendation: if the incident is dismissed or auto-resolved on the dashboard, close this. If it is still listed, the issue is doing its job and should stay open until it is cleared. I have not closed it, because the one fact that decides it is the one I cannot check.