[SauravYadav12]

Point 4.5, first part: which person's Aadhaar is exposed in a branch, where, and since when.

What it does

• fox pii aadhaar run reads every row of every text, number, array and JSON column for Aadhaar numbers (twelve digits, first 2–9, Verhoeff). It finds them alone, in free text, and inside JSON path by path, including a key that holds one. A card's sixteen digits or a phone number run on is not taken.
• The database filters each table for the shape, so only rows that may hold one leave it. Each table is one read-only transaction, with a time limit (5 min by default) and a 10 s lock wait. A table it cannot read is skipped and said so.
• fox pii aadhaar reports by column (counted in full) and by person: each number shown as UIDAI masks it (XXXX XXXX 0124), its places, and since when.
• fox pii aadhaar places [--person n] [--column s.t.c] [--gone] lists the rows, by primary key.
• Three routes under /api/branches/{name}/personal-data/aadhaar and a console page, Aadhaar exposure.

Decisions (taken 12 Nov)

• A place is kept as its column or path, the row's key and the last four digits (bb.aadhaar_runs, _columns, _places). Never the full number, and never a hash of it (UIDAI forbids hashes as reference keys). A JSON key holding a number is kept as *.
• Places of one number are grouped as one person by the run, with the numbers held in memory only.
• "Since when" is the first run that found a number in a place, or the row's created_at on a tracked table if that is earlier.
• Every row is read, filtered in the database.
• Same access as the scan: the branch's owner or an admin. Running it is Enterprise (personal-data); reading a report is free. Each run goes in the security log, with counts only.
• A place is gone only when the latest run read its table in full. A skipped table's places were not looked for, so they are not gone.
• A masked branch starts with no report, because its places name the source's rows. This adds the report's three tables to the masked branch's fresh Blackbox list.

Not in this PR

• 4.5b: query history, the audit log's forensic text and the Blackbox's statements (admins only).
• There is no vault yet (point 13).

Tests

• Integration 955/955. §11ar is new and checks:
  • numbers found by column and inside JSON; a card and a phone not taken
  • one number in three tables is one person; rows named by key; a tracked row's date used for "since when"
  • a table with no primary key named by ctid
  • no number, nor its first eight digits, stored anywhere; the tables not readable by a client role
  • nothing recorded in the Blackbox; the security log holds no digit of a number
  • a locked table is skipped and its places are not called gone; a removed number is gone; a place found again keeps when it was first found
  • out-of-range limits refused; who may call the API
  • the report carried by a branch made from it
• UI 62/62 plus the upgrade test (aadhaar.spec.ts: a run from the page, a person's rows, no whole number on screen, the report kept on the next visit, a removed number shown as gone).
• integration-v2 403/403, integration-f5 57/57, web unit 299/299, Go unit tests in both editions, vet.
• Notes on the runs:
  • The first integration run had one failure in my own new check: it pinned table counts that main's tables change. Fixed, and the rerun passed.
  • The first UI run had three failures. One came from my spec dropping its table, which a later spec applies to another branch, where the guardrail refuses the drop; fixed. The other two were a "Failed to fetch" flake on the Masking page and its knock-on failure; both passed on the rerun.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
foxbyte-get	Ready	Preview	Nov 11, 2026 8:07pm UTC