Files
jobtrackingapp/docs/planning/global-jobs-prompts/07_GJ_06_ALERTS_MATCHING.md
T

7.4 KiB

GJ-06 — Saved Searches, Alerts, Skills Matching and Application Tracking

Suggested branch: feature/gj06-alerts-matching

Objective

Help users act on relevant opportunities without overwhelming them: durable saved searches, reliable new-job alerts, explainable profession-neutral matching, and seamless use of Jobjakt's application tracker, Career Profile, CV Builder and cover letters.

Features

  1. Save and name multiple search profiles, including countries, tree scopes (not flattened children), radius, roles/skills, languages, source filters, work type and disabled-source status. Load/duplicate/edit/delete/suspend/restore; update saved profiles only when explicitly requested, with revision-safe persistence.
  2. New matching jobs: scheduled bounded evaluation (according to each provider's data rights), idempotent matching by canonical provider ID + changed state, per-user subscriptions and timezone-friendly daily/weekly/in-app/email frequency; pause/unsubscribe, quiet hours where supported, anti-spam and delivery failure recovery. Don't notify about expired/deleted jobs or leak another user's preferences.
  3. Occupation/skills/qualification matching: use explicitly stored Career Profile facts, source advertised requirements, ESCO relations and supported match semantics; show evidence (CV says, advert requests, not supplied), reasons and gaps. Never infer qualifications/regulated professional authorisation, fluency, licences or job eligibility from general similarity. No black-box score claiming hiring probability.
  4. Cross-language matches: original job ad remains authoritative. Display translated title/summary only if supported, attributed and clearly labelled; distinguish exact vs related suggestions. Allow users to restrict results to ad languages they understand.
  5. Saved vs tracked: Save job doesn't imply application submitted; Track Application opens established workflow, avoids duplicates and links permitted source metadata and CV/letter. Expired ad content obeys provider source lifecycle; user's own notes and status remain separate.
  6. Optional relevance ranking and explanatory weights: location, title, skills, language, schedule, salary (if provided), remote eligibility and user preferences. Avoid geography bias, sensitive-class inference, nationality discrimination and misleading eligibility statements. No automatic external application submission.
  7. AI inference can be added later only after approved security/semantic qualification; core matching must work with transparent rules and catalogued data.

QA scenarios

  • Teacher with pedagogy/subject preference, chef with evening shifts, nurse with mandatory authorisation, cleaner without formal qualifications, electrician with trade licence, part-time retail worker, remote English speaker, mixed-country mover and backend developer.
  • Same job from multiple providers, result withdrawn before alert, saved search changed mid-run, duplicate worker delivery, locale/timezone, overlapping searches, no results, disabled API source, invalid/missing salary/location and account deletion.

Checkpoints

GJ06-A saved-search storage; GJ06-B alert scheduling/dedupe; GJ06-C matching and explanations; GJ06-D tracker and documents; GJ06-E security/load/accessibility. Docs docs/global-jobs/06/. Commit/push checkpoints; final GO/CONDITIONAL GO/NO-GO and GJ-07 handoff. Stop.

Shared rules for every INT-GLOBAL-JOBS-01 stage

  • Product: Jobjakt, a general-purpose, commercial job-search and career-management SaaS. It is not an IT-only product. Current architecture includes React/TypeScript, .NET backend, MariaDB, an AI sidecar, existing Career Profile/CV/document/application features, and an established EN/NO localisation approach. Verify actual repository reality before making assumptions.
  • Entry gates: Do not implement new global-job-discovery features until the authoritative Phase 10 and product-review/development-entry decisions permit this initiative. Planning-only reconnaissance may precede them. If an entry gate remains NO-GO, produce safe analysis and stop before code changes.
  • Baseline: Find the latest accepted, integration-complete development commit by reading Git history and the latest authoritative acceptance reports. Do not assume main is current. main deploys production: NEVER merge to main or trigger production. Never change live MariaDB, Docker, Ollama, storage, secrets or other production services.
  • Branches: Use the specified independent stage branch from the latest accepted development integration history including the preceding accepted stage. Verify ancestry, remote, clean tree and existing branch collisions. Use checkpoint commits; push each validated checkpoint; verify remote HEAD equals local HEAD. Do not force-push. Do not advance to another stage without its actual entry criteria.
  • Autonomy: Investigate, design, implement, add tests, document, commit and push safe work without pausing for routine decisions. Stop only for external API agreements, new paid resources, security-risk acceptance, destructive changes, privileged infrastructure actions and production operations. Continue independent work when one provider or model capability is blocked.
  • Sources: Integrate only documented, authorised sources. Verify current licensing, commercial eligibility, credentials, permitted display, storage, cache lifetime, update/delete/tombstone, attribution, user-click-through and rate-limit rules. No covert scraping, private APIs, stolen cookies, bypassing anti-bot controls or fetching protected listing content without authorisation. An external-link-only source is not a direct searchable provider.
  • Data trust: All provider data, job descriptions and user-provided URLs are untrusted. Guard SSRF, XSS/unsafe HTML, prompt injection, HTML injection, unsafe redirects, credential leakage, denial of service and cross-user/tenant access. Do not present missing facts, inferred salaries, regulated-profession eligibility, or AI-generated job details as verified employer facts.
  • Availability: Preserve offline/disabled provider states. Use realistic fixtures in automated tests; any live contract test needs authorised test credentials and bounded rates. Never claim unavailable external API functionality passed.
  • User-facing quality: Desktop/tablet/phone, keyboard and screen-reader access, light/dark, EN/Bokmål plus future qualified locales, loading/empty/error states, responsive design, sensible defaults, performance, source transparency, internationalisation and accessible non-drag alternatives.
  • Data integrity: Source advertisements and user-owned saved jobs/applications are separate records and lifecycles. Preserve existing Career Profile, historical CVs, cover letters, saved applications, revisions, RD21 protections and MariaDB compatibility. Follow source rules for removing or masking withdrawn advertisements, while handling user-owned records under a separately justified retention policy.
  • AI: Existing live-model inference and semantic quality must remain gated unless separately qualified. Rule-based/ESCO-backed title suggestions and auditable matching should function without a generative model. Do not invent user qualifications or automate application submissions.
  • Evidence: At every checkpoint provide exact tests (pass/fail/skip/not run), security/coverage evidence, dated docs, commit hashes, branch and remote verification. Report individual stage GO / CONDITIONAL GO / NO-GO; separate production NO-GO from development readiness.