Leftovers the re-founding did not sweep: three undocumented env vars, ~420 LOC of dead exports, and four unbounded `getAll` helpers with no callers

[sroussey]

A 153,611-line deletion this clean deserves the small follow-up that finishes it. Measured at 2ab82ba; every item here is dead or undocumented, none is a correctness defect.

1. Three env vars read by production code, documented nowhere

$ git grep -ohE '(process\.env\.)SEC_[A-Z0-9_]+' -- src | sed 's/.*SEC_/SEC_/' | sort -u  > /tmp/code
$ cat .claude/CLAUDE.md README.md ARCHITECTURE.md docs/*.md | grep -ohE 'SEC_[A-Z0-9_]+' | sort -u > /tmp/docs
$ comm -23 /tmp/code /tmp/docs
SEC_GGUF_CONTEXT
SEC_GGUF_DIR
SEC_OPENAI_REASONING_EFFORT

Read at src/config/registerModels.ts:150, :167, :260. This is the live remainder of #338, whose other half retired with the extractor union — the two vars that issue named (SEC_SQLITE_CACHE_MB, SEC_FETCH_TIMEOUT_MS) are now in the table, and the extraction-nonce pair is gone with the extraction tier.

Worth asking whether SEC_GGUF_DIR / SEC_GGUF_CONTEXT should exist at all: node-llama-cpp is not in package.json's dependencies, and src/config/models.ts documents exactly two model roles ("There is no third role, and no per-command override matrix"). If the GGUF path is unreachable, deleting it is better than documenting it.

2. Dead exports the deletion left behind

Nine exported functions whose only occurrence in src/ is their own definition:

$ git grep -c hasLoiTriggerItem -- src
src/sec/forms/miscellaneous-filings/spac8kLoiTriggers.ts:1

symbol	file	LOC	why it is dead
hasLoiTriggerItem	sec/forms/miscellaneous-filings/spac8kLoiTriggers.ts	21	SPAC model left in b8c3787
hasRedemptionTriggerItem	sec/forms/miscellaneous-filings/spac8kRedemptionTriggers.ts	15	same
staffActionAbandonsRegistration	sec/forms/registration-withdrawal-termination/staffActionAbandonsRegistration.ts	39	RW/registration extractors left in defe9b7
isBadPersonField	types/edgar/bad-data.ts	120	person tier left in e7cb8fe
cleanHtmlDoc, foldDiacritics	util/dataCleaningUtils.ts	174	name normalization left with the resolvers
exemptOfferingFormSlug	sec/forms/exempt-offerings/form-slugs.ts	54	Form D/C/1-A storage tiers left downstream
validateLookback	cli/groups/sync.ts	—	orphaned by the a6caf23 CLI reorg
declaredVarcharWidth	config/alignPostgresColumnTypes.ts	—	orphaned by the registry shrink (94 → 17 entries)

~420 LOC. oxlint does not flag unreferenced exports, so nothing in CI will.

3. Four unbounded getAll() helpers, none of them called

src/storage/entity/EntityRepo.ts:

:79   getAllEntities()        → entityRepository.getAll()
:104  getAllEntityTickers()   → entityTickerRepository.getAll()
:121  getAllSicCodes()        → sicCodeRepository.getAll()
:157  getAllFilings()         → filingRepository.getAll()

$ for m in getAllFilings getAllEntityTickers getAllSicCodes; do git grep -n "$m(" -- src | grep -v EntityRepo.ts; done
   (no output)
$ git grep -n 'getAllEntities(' -- src | grep -v EntityRepo.ts
src/storage/entity/EntityTemporalRepo.ts:288:    return this.entityRepo.getAllEntities();

getAllEntities survives only as a forward from a method that is itself uncalled. getAllFilings() on a loaded database materializes the whole filings table — millions of rows — in one array. There is no caller today, which is the argument for deleting them rather than for leaving a loaded gun where the next feature can pick it up. The repo's own rule ("A bulk read is not a reason to reach for raw SQL … chunk only because SQLite binds one parameter per value") points the same way.

Verify

git grep -ohE '(process\.env\.)SEC_[A-Z0-9_]+' -- src | sed 's/.*SEC_/SEC_/' | sort -u > /tmp/code
cat .claude/CLAUDE.md README.md ARCHITECTURE.md docs/*.md | grep -ohE 'SEC_[A-Z0-9_]+' | sort -u > /tmp/docs
comm -23 /tmp/code /tmp/docs        # expect empty
bun run typecheck && bunx vitest run # after the deletions

Found during the 2026-09-07 review. Snapshot: workglow-dev/prd → analysis/grades/2026-09-07/sec-detailed.md.

[sroussey]

A tenth dead export the list misses, found while removing better-sqlite3 for #347:

isUniqueConstraintError — src/util/isUniqueConstraintError.ts, 38 LOC plus a 100-line test file.

$ git grep -n 'isUniqueConstraintError' -- src | grep -v 'isUniqueConstraintError\.'
   (no output)

Its only occurrences are its own definition and its own tests. It went dead with the identity tier — the test cases name canonical_person and canonical_company, which are the tables it was written for.

Two notes for whoever picks this up:

• It is not in the same category as the other nine. Those are leftovers with nothing to say; this one encodes real, verified backend behaviour (Postgres SQLSTATE 23505, and SQLite's wording) that would have to be rediscovered if a future caller needs it. Deleting it is still defensible — it is dead, and the knowledge is recoverable — but it is a judgement call rather than a sweep.
• If it is kept, it needs the fix that shipped on the claude/p1-sec-347-release-floor branch: @workglow/sqlite moved to node:sqlite, which reports every failure as code: "ERR_SQLITE_ERROR" and puts the specific one in a numeric errcode — so the "SQLITE_CONSTRAINT_UNIQUE" string it matched (a better-sqlite3 spelling) never fires, leaving SQLite with the English error message as its only signal. Verified on Node 24.20: UNIQUE index 2067, PRIMARY KEY 1555, and CHECK 275 / NOT NULL 1299 which must not match.

Either way the count in the issue title is ~460 LOC rather than ~420.

---

Generated by Claude Code