Date: 2026-06-18 Task: securva.net/research auto-regen pipeline (operator build).
incl. .db files - do NOT conclude "not reproducible" from the first/obvious dir. I checked ~/research/ (flat files) and declared the page numbers (116 orgs / 4948 hosts / 18.2% HSTS) "not reproducible / STOP" - a FALSE ALARM. The real source was /home/babakinzo/bounty/phase-intel.db (sqlite orgs+findings tables), which reproduced EVERY number exactly: COUNT(orgs)=116, SUM(host_count) over the NG-7 sectors=4948, COUNT(findings)=44, AVG(hsts_pct) per sector=18.2/48.5. The flat-file ~/research data was a DIFFERENT/partial dataset (1180-site lead scan + partial phase dirs) that coincidentally looked related. Reconciliation rule: grep the exact target numbers across ALL stores (find . -name '.db' too), and only STOP after the DB/structured stores are checked, not just the loose files. (The STOP-rather-than-guess instinct was right; the dataset enumeration was incomplete.)
git clone https://x-access-token:TOKEN@github.com/... PERSISTS the token into theclone's .git/config remote URL. Pushing that way leaks the PAT to disk. Either (a) clone with a CLEAN url and
push with an inline one-shot git -c ... / git push https://TOKEN@host that isn't stored, or (b) immediately
git remote set-url origin <clean-https> after. Always grep .git/config for the token after any
token-authenticated git op. (Scrubbed this run.)
reflects the USER's role, NOT a fine-grained PAT's Contents scope. The push still 403'd because the token was
read-only. Don't trust the perms API as proof of write capability - the actual git push (or a create-ref API
call) is the real test. On 403, STOP per guardrail (don't improvise other creds).
edits on research/index.html, sanity-gated, NULL-hsts -> 'n/a' never fabricated). Tested: clean diff = date only (numbers DB-derived + unchanged; page hard-coded a misleading 'Updated 2026-06-18' vs real data 2026-04-26). PR blocked on read-only token -> operator to provide Contents:write+PR token; re-scan deferred to upgraded box.