63b58e514d
New funders/funder_grants schema + ingest990pf monthly workflow: IRS BMF state file discovers NH private foundations (747), e-file index CSVs select their latest 990-PF filings, batch ZIPs stream through fflate (4/run cap, most-hits-first, deferred logged), grants-paid rows land in funder_grants, and funders with >=2 NH grants synthesize rolling grant rows (source irs_990pf, funder_ein linked) that flow through the existing embed+match pipeline. Scoring v2: funderPrecedentSubscore tiers repeated in-state giving (1/3/5/10 -> 8/15/20/25); easy win = >=65 total AND >=12 precedent (plan's precedent floor); scale is the full 0-100. Rolling deadlines pass the runway gate. Retrieval computes per-funder in-state counts and exposes funder_ein. Lead-quality gates from the first precedent run's failures: candidate orgs exclude NTEE T* grantmakers; self-matches gated by EIN + normalized name (NHDOJ registers foundations as charities, several without resolved EINs — the first run's top 'leads' were foundations matched to themselves). Live: ~6.5GB of IRS batches processed, 2,766 grants-paid rows, 123 synthesized foundation grants, 89 easy wins across 27 orgs, credible top-10 (AIDS Response-Seacoast -> Foundation for Seacoast Health, 25/25 precedent). 153 tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@novelpad/outreach-worker
DBOS executor process for the HelmDocs grant-match outreach engine. Runs the
scheduled workflows that keep the outreach schema's grant catalog fresh —
nightly ingestion from upstream sources and an hourly expiry sweep — decoupled
from any HTTP-facing app in this monorepo (mirrors the workflow-worker split
in novelpad-desktop).
Boot order (load-bearing)
src/main.ts imports ./workflows/ingest-grants.js and
./workflows/expire-grants.js before calling DBOS.launch(). Each of
those modules calls DBOS.registerWorkflow + DBOS.registerScheduled at
module-evaluation time — DBOS only dispatches scheduled/queued jobs for
functions that were registered before launch, so importing them after launch
(or not at all) silently means the cron jobs never fire.
The db handle is then threaded into each workflow module via its
set*Deps injector (setIngestGrantsDeps / setExpireGrantsDeps), also
before launch — DBOS serializes scheduled-function arguments, so a Drizzle
client can't be passed through the scheduler call itself. This is the same
module-scope-registry pattern novelpad-desktop's workflow-worker uses for
setStartDeps.
1. import workflow modules → registers ingestGrants / expireGrants
2. build pg Pool + drizzle(db)
3. set*Deps({ db }) → populates each workflow's registry
4. DBOS.setConfig(...)
5. DBOS.launch() → scheduler starts firing
Workflows
ingestGrants(0 3 * * *, nightly) —fetchGrantsGov(stub; real implementation calls the Grants.gov Search2 API,POST https://api.grants.gov/v1/api/search2) →normalize→ upsert viaserverInsertGrantsfrom@novelpad/outreach-core/server. NH state postings and 990-PF extracts land as additional fetch+normalize steps later.expireGrants(0 * * * *, hourly) — marks grants whose close date has passed as closed viaserverExpireClosedGrants, so they drop out of the active match/scoring pool.
Both are registered as a DBOS workflow and a scheduled function referencing
the same function object (DBOS.registerWorkflow then DBOS.registerScheduled)
— see the doc comments in src/workflows/*.ts for why the dual registration
is required.
Scripts
yarn dev—node --env-file=.env --env-file-if-exists=.env.local --import tsx/esm ./src/main.tsyarn build— esbuild bundle tobuild/main.js(--packages=external)yarn start— run the built bundleyarn typecheck—tsc --noEmit
Environment
Copy .env.example to .env and fill in DATABASE_URL (required — main.ts
throws on boot without it) and GCP_SERVICE_ACCOUNT_KEY_PATH (used by
future ingestion/scoring steps that call Google-hosted APIs).