Files
jobtrackingapp/automation/prompts/global-jobs-pack/04_GJ_03_OCCUPATIONS.md
T

36 lines
7.2 KiB
Markdown

# GJ-03 — Universal Occupation Autocomplete, Skills and Cross-Language Queries
**Suggested branch:** `feature/gj03-occupation-search`
## Objective
Deliver fast, useful occupation and job-title suggestions for **every sector**, available in different languages, without coding a developer-only dictionary or requiring AI inference.
## Design and build
1. Inspect search UI/backend and Career Profile, existing role categories and suggestions. Define distinction: occupation concept, advertised job title, related title, alias, skills, licence/qualification, free-text term and category. A text search like `weekend work` must remain possible.
2. Integrate a verified version of ESCO occupational concepts/labels/aliases/skills using suitable licensed API/dataset/cache. Where helpful map to national classifications including Sweden SSYK and UK SOC; maintain ID provenance/version and explicit unmapped cases. Do not assume ESCO's `no` language pack provides fully distinguished Bokmål and Nynorsk translations.
3. Build typeahead with debouncing/cancellation, typo tolerance, language-aware synonyms, ranked results, accessible keyboard selection, exact vs related query modes, optional skill chips. Present human-readable explanation for expansions across languages (e.g. `chef` ↔ `kokk`) and user control to turn them off.
4. Source signals: user-chosen occupations, verified Career Profile entries (with consent/config), common local terms, prior searches, and role terms from supported providers. Do not mine raw private CVs globally or leak user data into other tenants.
5. Support searches by job type and requirement not just formal title: part-time, evening shifts, weekend work, apprenticeships, no experience, teaching level, kitchen role, professional licensing. Filter capabilities must be source-aware, never fabricate unsupported advertised fields.
6. Multi-lingual matching can expand keywords if justified; preserve original title and advert in results. Distinguish exact-match results from related recommendations and avoid conflating unrelated occupations.
7. Generate a frozen multi-profession benchmark and evaluate suggestions for false positives, useful recall, language accuracy, query latency and index size. Include fallback to simple keyword on taxonomy outage.
## Acceptance matrix
Explicit scenarios: teacher, teaching assistant, chef, kitchen assistant, cleaner, nurse, healthcare assistant, electrician, plumber, carpenter, delivery driver, warehouse worker, shop assistant, waiter, accountant, public administrator, mechanic, software developer, agricultural labourer. Include NO/SE/UK title variants and source text. Ensure broad roles do not swamp precise title searches; 'nurse' shouldn't blindly match uncredentialed carers as an exact title.
## Checkpoints
`GJ03-A` taxonomy/licensing and mapping; `GJ03-B` search index/normalisation; `GJ03-C` suggestion UI; `GJ03-D` relevance controls and filters; `GJ03-E` benchmarks/accessibility/regression. Docs: `docs/global-jobs/03/`. Commit/push checkpoints. Report exact tested languages, source coverage and limitations. 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.