strelov1/freehire

Problem The candidate Profile page (/my/profile) has grown into 8 separate tabs (Profile, Contacts, Location, Skills, Experience, Education, Screening, Settings), each backed by its own component. As a result the page feels: Overcomplicated — too many sections for what is conceptually one object (the candidate's profile), forcing users to hunt across tabs for related fields (e.g. CV summary lives under "Profile" while education parsed from the same CV lives under a separate "Education" tab). Unclear — no visible indication of what's filled in vs. missing, or why a given tab exists as its own destination rather than a section of a longer page. Inconsistent — sections mix different UI patterns (inline autosave in some tabs, explicit Save in others; card-based layouts vs. form layouts) depending on which component happens to back the tab. Ask Redesign the Profile page's information architecture and visual consistency: reconsider whether 8 tabs is the right structure, unify the edi

Context #1998 landed the i18n infrastructure for the account section (locale resolution from users.language, path-gated to /my/**, the hand-rolled t()/defineMessages catalog mechanism) and fully translated /my/security, the shared shell/navigation (my/+layout.svelte, AccountNavRail), and the /my/profile tab-strip labels — English + Russian only. This was deliberately scoped as the reference pattern; see openspec/changes/i18n-my-account (now archived) for the full design rationale. Two things are explicitly deferred there and still open: 1. Fan out to the remaining /my/** pages (en/ru) Still English-only: /my/profile's eight tab views (ProfileForm, ExperienceBankView, CandidateContactsEditor, EducationCard, LocationCard, SkillsCard, ScreeningAnswersForm, AccountPreferences) — only the tab labels were translated in #1998 /my/activity /my/tracking /my/inbox /my/market-pulse /my/assistant /my/cvs /my/referrals /my/notifications /my/api-keys /my/submissions /my/contributions /my/credit

What A public page where anyone can type a skill, a role, or an industry and see whether our dictionaries know it. If we don't, the term is recorded in a table that a maintainer reviews by hand and turns into dictionary entries. Coverage check runs against the same code the pipeline uses, so the answer is the truth, not an approximation: skills — internal/skilltag (canonicalize + aliases) roles / categories / seniority — internal/classify industries — internal/industrytag (geo is a candidate too, but internal/location is a different beast — leave it out of v1) Why Every facet dictionary here is dict-only in production — never guess, emit nothing for unknowns (see AGENTS.md). That rule is right, and its cost is that growth is manual. Today the only growth loops are agent-driven mining (mine-skill-dictionary over what the LLM actually emitted) and the maintainer noticing a gap. This adds a third, cheapest loop: the people who read the site tell us what's missing. It also doub

What Every canonical skill in internal/skilltag should carry a one- or two-sentence plain-language description, surfaced on hover (and on tap, on touch) wherever a skill chip is rendered. Today the vocabulary has two sides: the slug (ci-cd, dbt, 1c) and the display label (CI/CD, dbt, 1C) — see internal/skilltag/labels.go. Neither tells a reader what the thing is. A candidate browsing filters, a job card, or a CV-match delta sees ~309 canonical tokens with no way to learn "dbt is a SQL transformation tool for data warehouses" without leaving the site. Why Filter discovery: people skip facets they don't recognize. CV match / skill-delta surfaces name skills the candidate is missing — a definition turns a bare gap into an actionable one. It is a cheap SEO/GEO asset: a glossary of ~300 IT skills with real definitions is a linkable, indexable surface. Shape (proposal, design owns the final call) Design first. Where does the description live and how is it revealed? Candidates: a toolt

Snapshot (prod, 2026-08-11): crelate currently has 0 active jobs/companies in the catalogue. Before running a harvest pass here: find out why — never onboarded past a stub, ingest broken/cooled down, or the board file is stale. Then decide directly: if crelate still has live postings worth pulling, fix the crawl (or onboard real boards) and re-check if it never carried anything worth keeping, propose dropping crelate from sources/ outright — no harvest pass needed for an empty source Part of #1758.