@hadoku/jobplatform-worker 2.32.35 → 2.32.37

package/migrations/0028_pipeline.sql

@@ -0,0 +1,51 @@
+-- V5 pipeline: what happens to an application after it is sent.
+--
+-- job_states already says where a posting stands for one person. V5 adds the
+-- states past "applied" (interviewing / offered / rejected — the column is
+-- free TEXT by design, see 0005, so those are a code-only change), the facts a
+-- person tracks per application, and an append-only timeline.
+--
+-- The tracking columns live on job_states rather than a table of their own
+-- because they mean nothing without a state: a posting is in someone's
+-- pipeline exactly when it has a job_states row, and that row is also what
+-- makes the posting immune to the daily cull (ingest.ts cullExpired), so a
+-- listing that closes while you are interviewing stays readable.
+--
+--   priority      1 high · 2 normal · 3 low; NULL = unset
+--   follow_up_at  the date (YYYY-MM-DD) the person means to chase it
+--   contact_name / contact_email
+--                 the recruiter or hiring manager, as the person wrote it down
+ALTER TABLE job_states ADD COLUMN priority INTEGER;
+ALTER TABLE job_states ADD COLUMN follow_up_at TEXT;
+ALTER TABLE job_states ADD COLUMN contact_name TEXT;
+ALTER TABLE job_states ADD COLUMN contact_email TEXT;
+
+-- The timeline. One row per thing that happened, never updated:
+--
+--   kind = 'state'      written by PUT /jobs/:id/state when the state CHANGES
+--                       (from_state → to_state; from_state NULL = was new)
+--   kind = 'note' | 'interview' | 'contact' | 'follow_up'
+--                       written by the person (POST /jobs/:id/events), with
+--                       occurred_at as they give it — an interview logged the
+--                       evening after happened that morning.
+--
+-- Only person-written rows can be deleted; a state row is the record of a
+-- transition and goes only with the job or the person (erase hook).
+CREATE TABLE IF NOT EXISTS job_events (
+	id INTEGER PRIMARY KEY AUTOINCREMENT,
+	job_id TEXT NOT NULL,
+	user_id TEXT NOT NULL,
+	kind TEXT NOT NULL,
+	from_state TEXT,
+	to_state TEXT,
+	note TEXT,
+	occurred_at TEXT NOT NULL,
+	created_at TEXT NOT NULL,
+	FOREIGN KEY (job_id) REFERENCES jobs(id) ON DELETE CASCADE
+);
+
+-- One job's timeline, and the cascade from jobs (job_id leads neither of the
+-- other two, and an unindexed cascade is what 0027 had to fix).
+CREATE INDEX IF NOT EXISTS idx_job_events_job ON job_events(job_id, user_id, occurred_at);
+-- Insights: one person's transitions over time.
+CREATE INDEX IF NOT EXISTS idx_job_events_user ON job_events(user_id, kind, occurred_at);

package/migrations/0029_blocked_companies.sql

@@ -0,0 +1,18 @@
+-- Companies a person never wants in their feed (from the JobPulse merge, where
+-- it was a localStorage list on one machine).
+--
+-- Keyed by LOWER(TRIM(company)), computed in SQL on both sides — at insert and
+-- in the feed's NOT EXISTS — so the key and the comparison cannot disagree
+-- about case folding (SQLite's LOWER folds ASCII only; doing it in JS on one
+-- side would not match the other for a non-ASCII name). `company` keeps the
+-- spelling the person blocked, for display.
+--
+-- A filter on the feed only: a blocked employer's postings stay in the shared
+-- corpus, and anything already in the person's pipeline stays there.
+CREATE TABLE IF NOT EXISTS blocked_companies (
+	user_id TEXT NOT NULL,
+	company_key TEXT NOT NULL,
+	company TEXT NOT NULL,
+	created_at TEXT NOT NULL,
+	PRIMARY KEY (user_id, company_key)
+);

package/migrations/0030_jobs_geo_keys.sql

@@ -0,0 +1,13 @@
+-- Where each posting is, as the places its free-text location names, for the
+-- feed's radius filter (near= / radius_miles=). Written at ingest by
+-- geo.ts `geoKeys` and backfilled by POST /ingest/backfill-geo:
+--
+--   '|san-francisco-ca|new-york-ny|'  every known place the string names
+--   ''                                 read, and no known place in it
+--   NULL                               not read yet — backfill pending
+--
+-- Pipe-delimited so the feed can test membership with one LIKE per nearby
+-- place ('%|seattle-wa|%') against a short list it computes from the radius.
+-- No index: the filter runs per candidate row alongside the feed's other
+-- WHERE terms, and a leading-wildcard LIKE could not use one anyway.
+ALTER TABLE jobs ADD COLUMN geo_keys TEXT;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@hadoku/jobplatform-worker",
-  "version": "2.32.35",
-  "gitHead": "e16c45d8f76063779904a75c3115f33668a69438",
+  "version": "2.32.37",
+  "gitHead": "808b4a95842c638f0d1840d97203dcc06383d710",
   "description": "Job listings aggregation and tracking dashboard - Worker package",
   "license": "MIT",
   "type": "module",