feat(automation): preserve gated roadmap queue and source prompts
This commit is contained in:
cesnimda
@@ -0,0 +1,66 @@
|
||||
# Jobjakt — I18N-01 MASTER ORCHESTRATOR
|
||||
## Full European Internationalisation, Localisation and Cross-Industry Language Support
|
||||
|
||||
### Mission
|
||||
Build Jobjakt into an international career-management application that can serve users throughout Europe in the appropriate local language(s) **and English**. This is an end-to-end platform localisation programme, not just translating React buttons. Include authenticated UI, onboarding, admin, accessible validation, backend errors, email/reminders, Career Profile/CV import/CV Builder/cover letters/PDFs, job discovery, occupation names, marketing interfaces and SEO contracts.
|
||||
|
||||
**Europe-wide scope is broader than the EU's 24 official languages.** Design locale registry, fonts, message engine, data contracts, testing and translation workflows for all European countries and major official/national/local languages, with a documented expandable path for regional/minority languages. Never claim every European language is already translated. A locale becomes public only after appropriate automated and human qualification.
|
||||
|
||||
### Business and UX principles
|
||||
1. **All occupations**, not developer-only: teachers, cooks, nurses, trades, retail, transport, public sector, graduates, etc.
|
||||
2. **Country does not equal language.** Store residence country, job search countries, interface locale, job-ad language filters and per-CV/letter language independently; do not couple country switch to forced translation.
|
||||
3. Suggest English and current-country local language(s) **first**, but allow any approved supported UI locale. Display native language name followed by English name, and preserve manual overrides across devices.
|
||||
4. Store BCP 47 locale tags and stable ISO 3166 country IDs; verify territory-language relationships from current authoritative datasets. Locale/script/country variations require correct fallback.
|
||||
5. Keep source job ads in their original language, alongside a labelled translation/summary only with rights and permission. Do not rewrite professional accreditation, employer statements or missing information.
|
||||
6. Preserve existing users' documents, language preferences, drafts, frozen PDFs, billing entitlements and RD21 revision safety. Default/fallback for legacy settings must be deterministic and documented.
|
||||
7. Provide explicit accessibility support, language direction and Unicode script coverage. Locale choice should never make a form unusable.
|
||||
8. Avoid wide manual string concatenation: support context, plural/gender/select, variable interpolation, rich text, time zones, number/currency and date formatting.
|
||||
9. Use machine translation/AI only as an explicitly labelled drafting aid, with terminology and human review. Never auto-send PII-containing CVs or private messages to external translators without separately approved consent, contracts and data controls.
|
||||
10. Public marketing may say a locale is supported only after that locale's complete release gate passes; availability differs across products, providers, countries and languages.
|
||||
|
||||
### Target coverage and sequencing
|
||||
**Phase 1 foundation:** existing English/Bokmål production behaviour (`en-GB` or existing canonical English tag, `nb-NO`); add appropriate Nynorsk (`nn-NO`) and Scandinavian languages where translation and validation resources permit. Preserve backward compatibility.
|
||||
|
||||
**Phase 2 broad EU coverage:** all 24 EU official languages: Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Irish, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish and Swedish. The EU list is a coverage baseline, **not** the definition of Europe.
|
||||
|
||||
**Phase 3 non-EU national/official languages and variants:** Norwegian Bokmål/Nynorsk, Icelandic, Ukrainian, Albanian, Serbian Latin/Cyrillic, Bosnian, Montenegrin, Macedonian, Turkish, Luxembourgish, Welsh, Swiss Romansh, Faroese, Belarusian and other European-country languages as verified. Evaluate European/transcontinental contexts (e.g. Georgian, Armenian, Azerbaijani, Russian) explicitly in a defensible region/market matrix rather than inferring from geography. Consider national locale variants such as `fr-CH`, `de-CH`, `it-CH`, `nl-BE`, `fr-BE`, `de-BE`, `en-IE`, `pt-PT`, and regional/minority candidates Catalan, Basque, Galician and Scottish Gaelic. This is an illustrative research inventory, not a claim that any language pack is currently shipped.
|
||||
|
||||
**Long-term:** a catalogue covering all approved European markets, with verifiable locale status and easy addition of further regional/minority languages without architecture rewrites. Never prevent unsupported-language users from using the reliable English fallback.
|
||||
|
||||
The repository's actual existing locale identifiers take precedence when migration or interoperability requires preserving them. Distinguish language tags like `el-GR` (Greek language) from third-party country/organisation labels.
|
||||
|
||||
### Workstream ordering
|
||||
- `I18N-00` — Baseline, complete surface inventory, Europe country/locale scope and acceptance plan.
|
||||
- `I18N-01` — Locale registry, user preferences, safe migration, fallback and formatting architecture.
|
||||
- `I18N-02` — Full React/authenticated UI, forms, admin, accessibility and error states.
|
||||
- `I18N-03` — .NET/Python/backend, queued jobs, emails, notifications, billing copy and diagnostics.
|
||||
- `I18N-04` — Career Profile, CV import, CV editor, cover letters, typography, PDFs and source-language integrity.
|
||||
- `I18N-05` — International job discovery: occupation taxonomy, suggestions, regional locations and source/ad language.
|
||||
- `I18N-06` — European translation supply chain, catalogues, terminology, coverage and human review.
|
||||
- `I18N-07` — Marketing/homepage locale contracts, country pages, SEO and content publishing gates.
|
||||
- `I18N-08` — Pan-European end-to-end QA, native review, performance, accessibility, release gates and handoff.
|
||||
|
||||
Run each file in order; when independent work is possible, record dependencies and maintain sequential acceptance/integration. For cross-project dependencies, **GJ** owns job-source and search logic and **LAUNCH-SITE** owns homepage visual design; I18N owns localisation contracts and reviews. If a dependent component is not ready, complete the interface/fixtures without inventing released functionality.
|
||||
|
||||
### Branch/integration contract
|
||||
Prefer `feature/i18n-00-audit` through `feature/i18n-08-acceptance` (planning branches where appropriate). Use a shared, explicitly approved, non-production integration branch/worktree, not concurrent edits to one checked-out worktree. Integrate only accepted stage commits in dependency order and run regression after each integration. Never auto-merge to production main. All automated execution must obey owner-controlled approval files **outside Codex-writable paths**; self-generated JSON PASS must not override independent gates.
|
||||
|
||||
### Standard per-locale release gate
|
||||
For each UI locale/market/surface:
|
||||
- Locale registry and fallbacks valid; ownership and licence checked; every *required* message key complete and syntactically valid; placeholders/variables/plurals match source and render correctly.
|
||||
- Critical journeys reviewed: registration, login/recovery, onboarding, dashboard, jobs, Career Profile, CV import/edit/export, emails, notifications, privacy/security, payments/pricing where applicable, admin errors.
|
||||
- Native/proficient reviewer signs off user-facing language (especially legal, billing, security and CV wording) via externally controlled approval; proper product-specific glossary. AI drafts are not automatically approved.
|
||||
- Font/script coverage, accents/diacritics, long labels, plural cases, dates/currency, keyboard/screen-reader labels and PDF exports tested; automated snapshots and realistic E2E pass.
|
||||
- Website country/locale availability and provider/job-ad languages accurately represented. SEO alternates only for actually published translated pages.
|
||||
- Approved and deployed language explicitly distinguished from staged/dev language. Partial locales hidden from public language picker, while `en` fallback remains available.
|
||||
|
||||
### Deliverables and location
|
||||
Produce `docs/i18n/` with audit, coverage matrix, terminology, locale registry, message inventory, translation process, screenshots, backend contracts, CV/PDF fidelity, job-discovery contract, marketing/SEO agreement, native sign-off, test results, blocker register, final acceptance. Produce machine-readable `LOCALE_CATALOG.json` and `LOCALE_SCHEMA.json` with statuses per surface, validated independently. Reuse existing authoritative documentation rather than creating incompatible duplicates.
|
||||
|
||||
### Gating and autonomy
|
||||
GJ-00 planning is reported complete locally at `0ec9f98`, with Git publication previously blocked. Pre-Phase-10 acceptance reported `5032ccb`; do not assume remote push or Phase 10 approval. I18N implementation is part of the post-Phase-10 and product-review roadmap; inspect and obey the current accepted gates. **Current permission, if those stages are not approved: research/planning only.** Do not run stages 01–08 without documented owner authorisation and their entry prerequisites.
|
||||
|
||||
For every stage follow its individual prompt and the common execution/evidence rules. Stop for missing material consent, commercial translation services, legal review, native approval or release/publication decisions. Work autonomously on other independent authorised safe tasks.
|
||||
|
||||
### Final master instruction
|
||||
Build and qualify European-wide localisation as a scalable capability. Follow files `01_I18N_00_*` through `09_I18N_08_*` in order, without skipping explicit gates. Do not promise full European language coverage merely because locale files exist. Commit/push validated non-production checkpoints, preserve evidence, request human review where required, and never merge to main or deploy automatically.
|
||||
@@ -0,0 +1,32 @@
|
||||
# I18N-00 — Europe-Wide Audit, Coverage Matrix and Implementation Specification
|
||||
|
||||
## Objective
|
||||
Perform independent full-stack inventory and produce a testable roadmap for full European localisation. This stage is **research and documentation only**, suitable to run while earlier development gates remain blocked. Read the master prompt first.
|
||||
|
||||
### Tasks
|
||||
1. Trace existing `en`, `nb` and related language handling across React, .NET, Python sidecar, DB, auth, marketing, public/legal pages, emails, billing, job enrichment, background queues, AI, errors, CV import, CV editing, PDFs, server logs and admin monitoring. Identify hardcoded UI text, database values mistaken for translated display labels, and language assumptions.
|
||||
2. Inventory every string with namespace, English source text, translation context, placeholders, sensitivity and owning component. Distinguish user content, source job ads and controlled UI strings. Include mobile, empty/loading/error states, ARIA, screen readers, toasts, generated filenames and export labels.
|
||||
3. Create a country/territory-to-language matrix for all European countries/markets, including multi-official, minority/regional and script variants. Cross-check using authoritative CLDR/territory data and relevant official country records. Include EU 24 and non-EU countries; distinguish official vs regionally recognised vs candidate support. Do not imply EU-membership or political recognition from language tags.
|
||||
4. Prioritise shipping waves by usage/verification feasibility, not by engineering bias. Include `en-GB`, `nb-NO`, `nn-NO`, `sv-SE`, `da-DK`, `fi-FI`, `is-IS` early candidates, then EU-24 and broader Europe. List all 24 EU official languages explicitly and map candidate locale codes; evaluate Serbia Latin/Cyrillic and Swiss variants. Do not commit to shipping a locale without translators/review capacity.
|
||||
5. Inspect actual library versions and decide whether to extend current i18n solution or migrate. Compare use of i18next/Intl vs FormatJS/ICU where relevant; evaluate compatibility with .NET localisation and message tooling. Prefer minimal coherent shared catalogs over duplicate systems.
|
||||
6. Model the boundaries between country of residence, search countries, location filters, UI locale, job ad language preferences, per-document output language and optionally preferred communication language.
|
||||
7. Build a detailed risks register: dates, plurals, gender, word order, RTL future-proofing, extended Latin/Greek/Cyrillic glyph coverage, Turkish casing, Serbian scripts, name ordering, accessibility, legal copy, GDPR and subscription markets.
|
||||
8. Define acceptance per locale *and per surface*, staged publication, fallback semantics and human/native review requirements.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/00/AUDIT.md`, `SURFACE_INVENTORY.md`, `EUROPE_COUNTRY_LANGUAGE_MATRIX.md`, `IMPLEMENTATION_PLAN.md`, `RISKS_AND_APPROVALS.md`, `BASELINE_TESTS.md`, draft `LOCALE_CATALOG.json` and validated schema. Include source URLs and verification dates for authoritative language lists. Give explicit integration contracts for Global Jobs and Launch Site.
|
||||
|
||||
### Acceptance
|
||||
No missing critical surface in the inventory; country/language coverage is not limited to EU; each proposed locale has planned status and ownership; no promised completed translations; no feature code changes. Verdict: PLANNING READY/BLOCKED; I18N-01 entry decision with real predecessor checks.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,34 @@
|
||||
# I18N-01 — Locale Registry, Persistence, User Preference and Formatting Foundation
|
||||
|
||||
## Objective
|
||||
Implement the reusable locale infrastructure that supports European countries, languages and script variants without linking UI language to country. Read the master and I18N-00 reports.
|
||||
|
||||
### Functional contract
|
||||
- Stable country codes, valid BCP-47 UI locale tags, separate job-ad language filters and per-document language settings. Model status and supported surfaces per locale; never use `country=language` assumptions.
|
||||
- Persist interface language per authenticated user with safe migration of legacy `en`/`no`/`nb` values, revision-aware updates, correct multi-device refresh and explicit preference precedence: user choice > explicit locale URL/app selection > onboarding choice > browser negotiation > safe English fallback. Record why each source was applied; do not silently override saved choices on IP/country changes.
|
||||
- Onboarding asks for country of residence and optionally desired countries for job search, without making either mandatory where not needed; suggest local official language(s) plus English. Support multiple search countries and switching search country without altering the UI language. Provide accessible language selector with native + English labels.
|
||||
- Implement typed locale registry, script variants, locale aliases, normalisation, safe fallback (e.g. `nn-NO` should not silently become `nb-NO` without an intentional policy), load on demand and backwards-compatible API/database changes. Reject invalid locale IDs safely.
|
||||
- Use `Intl` / CLDR for dates, times, plural categories, numbers, currencies, relative timestamps and formatting; preserve amounts/currencies and correct time zones. Do not convert NOK to GBP as if number formatting were FX conversion.
|
||||
- Document translation-message syntax and shared key conventions. Avoid concatenating English fragments or unsafe HTML interpolation. Provide safe structured variables and escaping.
|
||||
- Test authenticated and signed-out persistence, multi-device conflicts, invalid locales, fallbacks, local storage migration if applicable, browser negotiation, SSR/prerender locale contexts if applicable, European names and scripts.
|
||||
|
||||
### Checkpoints
|
||||
I18N-01A model/schema/migration; 01B locale registry/fallback/formatting; 01C account/onboarding/preferences UI; 01D multi-user/tenant tests and integration.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/01/LOCALE_MODEL.md`, `MIGRATION_AND_FALLBACK.md`, `USER_PREFERENCES.md`, `FORMATTING_TESTS.md`, updated validated locale catalogue/schema, migration/reversal instructions.
|
||||
|
||||
### Exit
|
||||
No regressions to existing English/Bokmål users; new locale UI options remain hidden until translated/accepted; source job and CV content unchanged; real MariaDB and browser tests; clean accepted non-production handoff to I18N-02.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,33 @@
|
||||
# I18N-02 — Comprehensive React UI and Accessibility Localisation
|
||||
|
||||
## Objective
|
||||
Remove hardcoded user-facing strings and achieve total namespace coverage of the accepted React application, including new CV, Dashboard and Admin interfaces. Do not infer translation completeness from number of files.
|
||||
|
||||
### Tasks
|
||||
1. Inventory all routes and components at the current commit: sign-in/recovery, registration/onboarding, dashboard, jobs/Kanban/details, Career Profile, CV templates/builder/editor/undo-redo, CV import/review, letters, analytics, settings, subscription, admin processing monitor, help, and errors/empty/loading states. Translate visible chrome and accessible text, not user-entered data.
|
||||
2. Extract to stable, contextual message IDs, with descriptions for translators. Preserve ICU plural/select, variable type contracts and punctuation. No concatenated partial sentences. Test values containing special characters; no XSS introduced by translated rich text.
|
||||
3. Add safe language switching without losing unsaved edits, changing job search settings or restarting a CV import inadvertently. Persist via I18N-01 preferences; show current option native name and English equivalent; English must remain accessible.
|
||||
4. Handle German/Finnish label expansion, accented Latin, Greek/Cyrillic, Turkish casing, RTL layout readiness (only activate RTL where an approved locale warrants it). Use CSS logical properties when sensible, preserve keyboard focus and touch targets.
|
||||
5. Introduce developer checks for untranslated hardcoded literals, missing/unused message IDs, malformed interpolations, unlocalised aria-labels, fallback gaps and dynamic notifications. Avoid blindly translating component names, employers and user records.
|
||||
6. Test language changes with dirty forms and concurrent saves; preserve RD21 and CV revisions; update visual tests with representative long strings and pseudo-locales.
|
||||
|
||||
### Checkpoints
|
||||
I18N-02A string inventory/extraction; 02B critical account/job/CV flows; 02C dashboard/admin/settings/billing surfaces; 02D accessibility/responsive/localisation smoke; 02E full frontend regression.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/02/FRONTEND_MESSAGE_COVERAGE.md`, `UI_SCREENSHOTS.md`, `ACCESSIBILITY.md`, `LOCALE_SWITCHING.md`, `TEST_RESULTS.md`; linter/CI missing-key checks and pseudo-localisation harness.
|
||||
|
||||
### Acceptance
|
||||
100% of required message IDs extracted for every affected surface; existing released locales stay complete; new draft language packs cannot leak into public selector; no loss of unsaved data; accessible and responsive. No auto-publishing drafts.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,34 @@
|
||||
# I18N-03 — Backend, Email, Notifications, Jobs and Operational Messages
|
||||
|
||||
## Objective
|
||||
Localise backend-facing user messages, communication templates and async workflows so a European-language UI does not degrade to English-only email/error flows or misinterpret locale-dependent data.
|
||||
|
||||
### Tasks
|
||||
1. Inspect ASP.NET APIs, validation errors, typed error codes, authorization messages, scheduled background jobs, mail providers/templates, reminders, application status events, strategy generation, import processing, admin diagnostics and Python sidecar responses.
|
||||
2. Prefer stable machine-readable error codes with localisation on the presenting client; localise truly server-rendered communications at source. Do not return translated unstructured errors as API contracts relied on by frontend automation.
|
||||
3. Persist locale selection *at event creation* (or establish explicit current-preference policy) so queued email, reminders and background events render deterministically even if language changes later. Preserve UTC timestamps internally and localise display based on timezone/locale.
|
||||
4. Translate email subject, preview, button, footer and accessible plain-text parts for account verification, password reset, application reminders, import results and relevant notifications. Validate safe escaping in HTML and text; do not accidentally translate tokens, URLs, codes, user CV content or email addresses.
|
||||
5. Make plural/time/number formatting consistent across .NET, React and Python; design locale-aware error detail for admin logs while keeping immutable invariant error codes. Avoid PII in logs; don't create a multilingual free-text search dependency on logs.
|
||||
6. Pricing, billing and legal messages must use approved market-specific wording and actual tax/currency entitlements; require legal/owner review. Language selection must not change payment currency or jurisdiction.
|
||||
7. E2E test delivery in isolated Mailpit/test setup, queue retries, wrong/missing locale, recipient locale, cancellation, language change mid-queue, and tenant isolation.
|
||||
|
||||
### Checkpoints
|
||||
I18N-03A backend errors/contracts; 03B email templates; 03C queued events/notification consistency; 03D billing/legal boundary and full integration tests.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/03/BACKEND_ERRORS.md`, `EMAIL_TEMPLATES.md`, `QUEUED_LOCALE_POLICY.md`, `BILLING_LEGAL_GATES.md`, `TEST_RESULTS.md`.
|
||||
|
||||
### Acceptance
|
||||
Critical user communication is localised for each activated locale; all error codes remain stable; no secret/PII leakage; critical legal and billing copy remains blocked pending human approvals. Actual test results and source branch recorded.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,34 @@
|
||||
# I18N-04 — Career Profile, Docling Import, CV/Letter Editors and PDF Localisation
|
||||
|
||||
## Objective
|
||||
Support European locale output for CVs and cover letters without fabricating, silently translating or overwriting user career data. Preserve previous PDF fidelity, historical versions, templates and RD21 integrity.
|
||||
|
||||
### Tasks
|
||||
1. Audit Career Profile, CV editor, template captions/placeholders, import review, Docling language detection, sidecar validation, letter builder, output rendering/print pipeline and existing CV language metadata. Define which content is UI (translate) versus user-authored career facts (never automatically translate).
|
||||
2. Each CV/letter independently chooses its output language (e.g. an English CV and Norwegian CV can coexist regardless of interface/job-country settings). Design explicit *Translate document* workflow only if separately approved, with visible diff, source provenance and per-field human approval; no background rewriting of achievements or qualifications.
|
||||
3. Localise template built-in headings and date conventions; preserve original employer/institution/certification names, accepted per-document overrides and frozen/submitted revisions. Use actual CV language for headings, not browser language when exporting.
|
||||
4. Test licensed fonts and renderers for extended Latin, Greek and Cyrillic; add further scripts when approved. Verify PDF text selectable/extractable, line breaks, hyphenation, page breaks, contact information and multi-page sections. Font licensing must be reviewed; do not attach proprietary fonts.
|
||||
5. For source CVs in multiple languages, evaluate Docling layout/section recognition separately from AI semantic accuracy. Record unsupported languages and ambiguity; don't claim automatic CV parsing works in every European language because UI translations exist. Preserve original snippets and allow correction.
|
||||
6. Validate per-locale date, month names, partial date precision, country-specific address/phone conventions without inventing missing fields. Verify UI switch while editing does not mutate frozen revision or undo stack.
|
||||
7. Add realistic synthetic fixtures spanning occupations (teacher, chef, nurse, electrician, retail, admin, driver, developer), accents, Greek/Cyrillic, long European names and differing qualifications. Review national licensing terms cautiously.
|
||||
|
||||
### Checkpoints
|
||||
I18N-04A document locale model; 04B template/editor/import translation; 04C multi-script PDF/fonts; 04D data integrity/real MariaDB/PDF E2E; 04E human PDF qualification package.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/04/CV_LANGUAGE_MODEL.md`, `IMPORT_LANGUAGE_LIMITATIONS.md`, `FONT_SCRIPT_MATRIX.md`, `PDF_FIDELITY.md`, `MANUAL_REVIEW.md`, `TEST_RESULTS.md`.
|
||||
|
||||
### Acceptance
|
||||
An English UI can create a Swedish CV, a Norwegian UI can create an English CV, and switching UI language changes no career fact; historical revisions remain untouched; supported scripts survive PDF; unqualified AI document translation stays disabled.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,34 @@
|
||||
# I18N-05 — Multilingual Cross-Industry Job Discovery and Occupation Search
|
||||
|
||||
## Objective
|
||||
Provide language-aware international job discovery in partnership with INT-GLOBAL-JOBS-01. **All occupations, not just tech.** This stage handles language semantics and contracts; do not rebuild provider integrations already delivered by GJ-01–08.
|
||||
|
||||
### Tasks
|
||||
1. Inspect accepted Global Jobs architecture, GJ-00 provider rights and GJ-01 country preferences. If GJ runtime not yet accepted, implement/test locale interfaces and synthetic provider fixtures, and mark live integration deferred rather than claiming release.
|
||||
2. Use authoritative occupation taxonomies (e.g. ESCO where permitted) to build multilingual occupation label/alias search, keyword autocomplete and exact-vs-related occupation selection. Test teachers, chefs, healthcare, retail, cleaning, manufacturing, logistics, finance, trades, office and software jobs. Don't infer professional licensure from a matching title.
|
||||
3. Distinguish user search text language, occupation concept ID, original ad language, optional translated summary language and UI locale. A query `teacher` should be able to match approved related titles in the chosen target market only where the provider offers the data and matching has evidence. Show suggested aliases rather than silently broadening exact searches.
|
||||
4. Language filters must support multiple ad languages independent of interface locale. Expose original description first; label source vs translated text, timestamp, incomplete details and provider-specific display restrictions. No scraping of FINN/Indeed/restricted providers; obey rights/retention/update/deletion.
|
||||
5. Locale-aware location names: preserve stable country/region/town IDs and display appropriate localized names/aliases without corrupting hierarchical Warwickshire→Warwick selection or Norway Vestfold/Bergen cases. Do not use translated free text as geolocation identity.
|
||||
6. Normalise metadata such as employment type, shifts, part-time, contract, salary/currency display, dates, seniority and qualifications without inventing missing fields. Job matching must distinguish evidence, inferred candidate suggestions and unverified requirements.
|
||||
7. Cross-language search tests across Norway, Sweden and UK initially, expandable to Europe. Ensure no profession is structurally excluded; demonstrate title ambiguity and multilingual names, regional variants, diacritics and provider language limitations.
|
||||
|
||||
### Checkpoints
|
||||
I18N-05A provider/ESCO contracts; 05B multilingual aliases/autocomplete; 05C ad language/detail presentation; 05D locale-aware geography and filters; 05E relevance and rights regression.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/05/OCCUPATION_LANGUAGE_MAP.md`, `SOURCE_RIGHTS_AND_LANGUAGES.md`, `SEARCH_LANGUAGE_SEMANTICS.md`, `GEO_DISPLAY_RULES.md`, `CROSS_INDUSTRY_TESTS.md`.
|
||||
|
||||
### Acceptance
|
||||
Source rights respected, no invented full descriptions, no job filtering based on UI locale, region IDs stable, and all-sector synthetic corpus passes. Country-specific sources remain accurately gated.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,35 @@
|
||||
# I18N-06 — European Translation Catalogues, Quality Workflow and Locale Launch Gates
|
||||
|
||||
## Objective
|
||||
Build a sustainable translation operation capable of shipping Jobjakt to all intended European markets through phased, provably complete language packs. This must create substantive translation/catalogue tooling, not just English strings copied under new locale codes.
|
||||
|
||||
### Tasks
|
||||
1. Read I18N-00 coverage plan; build a versioned translation corpus with source language, namespace, translator notes, context screenshots, placeholders, plural/select variants, glossary references, review status and feature ownership. Export/import to standard formats (JSON/ICU/XLIFF/PO as compatible with chosen library); preserve keys and comments.
|
||||
2. Seed **actual translations** for prioritised locales through permitted translation workflows. Default first wave may be English, Bokmål, Nynorsk, Swedish, Danish, Finnish and Icelandic, but check reviewer availability and owner priorities. Then cover EU 24 and non-EU country languages per the verified country matrix. Document each pack's true progress rather than making all 40+ languages appear complete.
|
||||
3. Create approved terminology for Job Applications, Career Profile, CV, résumé, cover letter, interview, shift, apprenticeship, seasonal work, workplace, salary, qualifications, nursing/teaching licences and other all-industry job vocabulary. Avoid English source ambiguity and misleading literal translations.
|
||||
4. Use machine translation/LLM only to draft *public template/UI strings* with appropriate licensed tooling; never transmit private CVs, user emails or tokens. Human proficient/native reviewers must approve critical copy; include a reviewer workflow and immutable approval evidence outside Codex control. Explicitly label unreviewed machine translations.
|
||||
5. Implement automated gates: 100% required keys for eligible active locale; parse messages; compare placeholders/types; CLDR plurals/select; HTML escaping; dangerous/empty strings; duplicate keys; gender/case assumptions; hardcoded-string detection; screenshot/text-overflow checks; pseudolocalization; untranslated source-identical checks with exemptions for proper nouns.
|
||||
6. Implement locale statuses `planned`, `draft`, `machine_draft`, `review_required`, `reviewed`, `qa_passed`, `release_approved`, `released` (or project-compatible equivalent) per namespace/surface. Prevent draft packs from appearing as supported public locales; allow safe English fallback during development.
|
||||
7. Generate automated coverage dashboards with counts by key, namespace, blocker severity, reviewer and date, and source-text change invalidation. A change to critical source copy must reopen affected translations; no silent stale publishing.
|
||||
8. Include legal/privacy/security/payment template sign-off by qualified reviewers; do not accept machine translations as legally adequate. Research whether regional minority languages need dedicated reviewers before committing to a public timeline.
|
||||
|
||||
### Checkpoints
|
||||
I18N-06A translation workflow/tooling; 06B terminology and foundational packs; 06C EU 24 staged corpus; 06D non-EU/variants corpus and review queue; 06E automated QA and per-locale release gates; 06F approvals and evidence handoff.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/06/TRANSLATION_PIPELINE.md`, `EUROPE_ROLLOUT_MATRIX.md`, `GLOSSARY.md`, `HUMAN_REVIEW_PLAN.md`, `CATALOG_COVERAGE.md`, `LOCALE_RELEASE_GATES.md`, plus actual validated resource files and CI tooling. List every language's implemented/reviewed/released percentage by *required* namespaces; distinguish draft from accepted.
|
||||
|
||||
### Acceptance
|
||||
Can add any new approved European locale without code rewrite; no unreviewed language claimed supported; real locale packs and reproducible checks delivered; no fake 100%-complete counts, no self-generated native approvals.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,33 @@
|
||||
# I18N-07 — Multilingual Homepage, Country Pages and SEO Contracts
|
||||
|
||||
## Objective
|
||||
Integrate the localisation platform with LAUNCH-SITE-01's public site and future European market pages, without unapproved homepage design decisions or deceptive marketing claims.
|
||||
|
||||
### Tasks
|
||||
1. Inspect homepage redesign state and owner mockup approval. If visual redesign has not been approved/implemented, deliver translation/SEO schemas and fixtures only; DO NOT bypass the LAUNCH-SITE mockup and owner-choice gate.
|
||||
2. Define market (`GB`, `NO`, `SE`), content locale (`en-GB`, `nb-NO`, `sv-SE`) and publication state as separate dimensions. A resident of Norway can view `en-GB`/English Norwegian-market content without unwanted redirects or forced Norwegian.
|
||||
3. Provide multilingual marketing catalogs for feature descriptions, FAQs, CTAs, pricing explanations, navigation, legal and accessibility labels; include genuine approved screenshots with locale-specific UI where available. No fake users/testimonials or claims of unavailable AI/provider integrations.
|
||||
4. Design crawlable, deterministic market/locale routes that don't collide with auth or existing app routes. Validate canonical URLs, alternate `hreflang`, `x-default`, XML sitemaps, social cards, accurate metadata, noindex for drafts/duplicates and page-specific language metadata. SEO targets actual translated, approved pages only.
|
||||
5. Add a release catalogue binding each marketing claim to deployed feature version, country/provider availability, subscription entitlement and approved translated copy. Marketing edits must not auto-publish unapproved capabilities or new locales.
|
||||
6. Test browser URL locale selection, persisted preferences, direct links, language switch, unsupported locale fallback, no redirect loops, mobile visual overflow, SEO tags and multi-market duplicates. Design preview of country pages for Norway, Sweden and UK with honest release-state toggles.
|
||||
|
||||
### Checkpoints
|
||||
I18N-07A market+locale content contracts; 07B SEO routes/metadata within approved site architecture; 07C claims and publishing gates; 07D localised screenshots and QA.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/07/COUNTRY_LOCALE_ROUTING.md`, `HREFLANG_SITEMAPS.md`, `MARKETING_RELEASE_CONTRACT.md`, `LOCALISATION_QA.md`; use `docs/launch-site/` as authoritative source where already defined.
|
||||
|
||||
### Acceptance
|
||||
Only approved launched locales are discoverable/indexed, country-specific copy reflects actual availability, no bypass of visual owner approval, no unapproved public homepage deployment.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
@@ -0,0 +1,35 @@
|
||||
# I18N-08 — Europe-Wide QA, Human Linguistic Acceptance and Release Handoff
|
||||
|
||||
## Objective
|
||||
Conduct rigorous end-to-end localisation qualification across supported European markets. Assess foundational platform readiness separately from each locale's actual release readiness.
|
||||
|
||||
### Tasks
|
||||
1. Build a coverage matrix crossing **language × application surface × country × profession × device**. Representative synthetic occupations include teacher, cook, nurse, construction worker, electrician, driver, cleaner, retail employee, office administrator and software developer.
|
||||
2. Execute automated test suites with exact process exit codes and commit-bound reports: backend, frontend, real MariaDB, Python, browser, existing RD21 revisions, CV import, CV templates/PDF fidelity, queued jobs and email, Global Jobs search, admin diagnostics, public routes, accessibility, SEO and security. Preserve existing passing baselines.
|
||||
3. Exercise realistic user journeys in selected accepted locales: new user onboarding (country and language), account recovery email, saved searches, job discovery, application save, import multilingual CV, edit, per-document output language, generated letter, export PDF, reminder notification, language switch, re-login, profile deletion/export if supported.
|
||||
4. Test linguistic edge cases: Polish and Slavic plural forms, Irish/Welsh patterns, Finnish inflection, German expansion, French/Spanish gender, Turkish casefolding, Greek accents, Nordic diacritics, Serbian Latin/Cyrillic, Ukrainian Cyrillic; validate supported locale rendering with real native review where possible. Avoid claiming language correctness based only on software tests.
|
||||
5. Verify dates, salary currency display (without FX conversion), time zones, DST transitions, numeral formatting, field validation, address formats and partial date precision. Check screen-reader locale, focus, long-label responsive layout, PDF glyph embedding/selection and email deliverability in isolated test systems.
|
||||
6. Verify all unshipped languages are honestly marked and excluded from public selectors and hreflang/sitemaps. Allow English fallback for unsupported markets. Independent owner/native reviewer approvals must be externally authenticated and not creatable by Codex.
|
||||
7. Perform threat and privacy review of translated HTML, malicious placeholders, unsafe markdown, locale parameter injection, job ad translated content, PII sent to translators, SSRF/external content and cross-tenant locale preferences. Do not mark unresolved serious vulnerabilities accepted.
|
||||
8. Create the final per-market launch matrix, with separate GO/CONDITIONAL/NO-GO for architecture, app, backend, CV, source/job data, communications, marketing and each locale. Estimate missing reviewer and translation work honestly. Distinguish development completion from deployment readiness.
|
||||
|
||||
### Checkpoints
|
||||
I18N-08A coverage and test corpus; 08B automated regression; 08C visual/PDF/email and accessibility; 08D linguistic/native review coordination; 08E security/release gates; 08F final acceptance and roadmap handoff.
|
||||
|
||||
### Deliverables
|
||||
`docs/i18n/08/ACCEPTANCE.md`, `LOCALE_RELEASE_MATRIX.md`, `HUMAN_TEST_PACKAGE.md`, `REGRESSION_RESULTS.md`, `SECURITY_AND_PRIVACY.md`, `PRODUCTION_HANDOFF.md`, validated updated `LOCALE_CATALOG.json` and `LOCALE_SCHEMA.json`.
|
||||
|
||||
### Acceptance
|
||||
Overall architecture may be GO while some/most European locales remain DRAFT or BLOCKED. No unqualified claims of "all Europe is live." Publish only locales with owner-approved, native-reviewed, critical-flow-complete status. No main merge/deployment; handoff to Security Audit and Release Readiness with exact outstanding tasks.
|
||||
|
||||
---
|
||||
|
||||
### Execution and evidence rules (mandatory in every stage)
|
||||
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
|
||||
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
|
||||
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
|
||||
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
|
||||
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
|
||||
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
|
||||
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
|
||||
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.
|
||||
Reference in New Issue
Block a user