Build a hosted labor market analytics platform with custom LLM scoring layers, starting with BLS data and an interactive treemap UI.

You are building a fresh implementation inspired by the karpathy/jobs repository.
Treat the repository as a reverse-engineering reference, not as the default destination codebase.
Infer the product, architecture, entities, and flows from the reference repository, then rebuild the core system intentionally from scratch.
Do not blindly clone the original repo. Do not default to patching or refactoring it in place.
Build in small phases and keep the first version focused and maintainable.
Product thesis: Enable HR leaders and economists to explore occupation data with custom AI-generated metrics, starting with employment projections and AI exposure.
Commercial/product framing: Current labor market data tools are static and one-size-fits-all. By allowing users to define custom scoring dimensions via natural language prompts and visualizing them on a treemap, we provide a flexible, decision-driven analytics platform that turns BLS data into actionable insights.
Target user: HR analytics teams in large enterprises, economic research firms, and career advisors who need to assess workforce trends and risks.
MVP scope:
- Interactive treemap visualization of BLS occupations where area equals employment and color maps to a selected metric (BLS growth outlook, median pay, education requirements, or AI exposure).
- Support for at least one custom LLM scoring layer defined by natural language prompt, with results displayed as a color overlay on the treemap.
- User authentication system to persist and manage custom scoring layers.
- Automated weekly data pipeline to scrape and update BLS data from the OOH website.
- Basic admin panel to trigger data refresh and view high-level usage metrics.
- Occupation detail page showing BLS attributes and a breakdown of all scoring results for that occupation.
Stack assumptions:
- Python backend (FastAPI) for API and pipeline orchestration, mirroring the repo's Python scripting approach.
- React frontend with D3.js for treemap visualization (repo uses static HTML; a rebuild requires a proper frontend framework).
- PostgreSQL database for structured occupation data, user accounts, and scoring layers.
- LLM integration via OpenAI API (similar to score.py in the repo) for sentiment scoring.
- Playwright and BeautifulSoup for scraping, as evidenced by pyproject.toml dependencies.
- Docker for containerization to ensure consistent data pipeline execution.
- Stripe for subscription billing, assumed based on commercialization path.
Key entities:
- Occupation: id, title, slug, description, median_pay_annual
- User: id, email, hashed_password, subscription_tier, created_at
- ScoringLayer: id, user_id, name, prompt, scores_json
Core pages / routes / flows:
- Treemap Dashboard (/): Primary view showing interactive treemap with controls to toggle between default and user-created scoring layers.
- Create Custom Scoring Layer (/layers/create): Form where user enters a natural language prompt and initiates LLM scoring across all occupations.
- Layer Management (/layers): List of saved custom scoring layers with options to view, rename, or delete.
- Occupation Detail (/occupations/{slug}): Deep-dive page for a single occupation, showing all scraped attributes and a breakdown of every saved scoring result.
- User Authentication (/login, /signup, /logout): Handles sign-up, login, and session management.
Backend services / modules:
- Scraping Service: Scrape individual BLS OOH occupation pages, parse HTML to extract structured data, and upsert records into PostgreSQL.
- Scoring Service: Accept a user prompt, format it with occupation context, call the LLM API, and store normalized scores.
- API Service: Expose REST endpoints for treemap data, occupation details, and layer management. Handle authentication and authorization.
- User Service: Manage user accounts, subscription tiers, and stored custom layers. Integrate with Stripe for billing.
Do not build yet:
- Real-time websocket updates for treemap (static refresh is sufficient).
- Mobile native apps (focus on responsive web).
- Public API for third-party developers until core product is stable.
- Advanced caching with Redis before traffic proves need.
- Collaborative workspaces or team sharing features.
- Integration with HRIS or talent management systems.
Major risks / blockers:
- LLM API cost and latency could make custom scoring prohibitive if not optimized; need model selection, batching, and prompt minimization.
- Scraping BLS and O*NET is brittle; site changes could break data ingestion without warning, requiring ongoing maintenance.
- Market risk: HR teams may not perceive enough value in custom scoring to pay, compared to free BLS data and existing analytics tools.
- Data licensing (no license on repo, BLS data is public domain but O*NET may have terms) could complicate redistribution.
Work in phases. After each phase, summarize what was built, what remains, and which assumptions from the reference repo you intentionally did or did not keep.

Phase 2 core flow

Objective: Build the interactive treemap visualization and hardcode the original AI exposure layer.

Deliverables:
- React app with D3.js treemap component receiving data from API.
- Toggle control for default layers: Growth Outlook, Median Pay, Education, AI Exposure.
- Responsive layout adapters for mobile/tablet.
- Pre-computed AI exposure scores migrated from repo's score.py output.
- Exit: Application matches functionality of karpathy.ai/jobs demo.
- Exit: Layer toggling updates colors instantaneously.
- Exit: Treemap is interactive (zoom, tooltip) and performant with 342 rectangles.

Rules:
- Implement the core pages, routes, and backend modules needed for the happy path in the fresh build.
- Use the reference repo for behavior and architecture cues, not as the code target.
- Preserve maintainability and add only the minimum comments needed.

Start by reverse engineering the reference repository, then implement the fresh build in the smallest clean sequence.

Deploy and finalization

Objective: Prepare the implementation for release, verification, and handoff.

Deliverables:
- Verify the main flows work.
- Check configuration, environment assumptions, and release blockers.
- Summarize remaining risks and suggested follow-up work.

Rules:
- Do not add speculative infrastructure.
- Focus on practical release readiness, tests, and explicit known gaps versus the reference repo.

Start by reverse engineering the reference repository, then implement the fresh build in the smallest clean sequence.