X-Hiring 聚合 V2EX、电鸭社区与谁在招人的互联网招聘信息，并使用 Cloudflare Workers AI 生成职位摘要。

• 多源聚合 - 抓取 V2EX、电鸭社区与谁在招人的公开招聘信息
• AI 摘要 - 使用 Workers AI 提取职位标题、摘要及可选的地点、岗位、薪资、年薪、性别和学历字段
• 招聘筛选 - 支持关键词、日期、结构化职位字段和趋势筛选
• 相关职位 - 根据规范化标签推荐相似职位
• RSS - 提供 /feed.xml 订阅，并使用 Cloudflare KV 缓存
• Cloudflare Runtime - D1、KV、Queues、Cron、Workers AI 和 AI Gateway 全部运行在 Worker 架构

x-hiring/
├── apps/
│   └── web/                      # Full-stack application (port 3002)
│       └── src/
│           ├── routes/           # File-based routing
│           │   ├── (app)/        # Recruitment pages
│           │   └── api/          # Health, ingestion, auth and RPC handlers
│           ├── components/
│           │   ├── ui/           # shadcn/ui components
│           │   ├── shared/       # Shared components
│           │   └── features/     # Feature-specific components
│           ├── lib/              # Utilities (auth-client, utils)
│           ├── hooks/            # Custom React hooks
│           └── stores/           # State management
│
├── packages/
│   ├── api/                      # oRPC entrypoints + routers/services
│   │   └── src/
│   │       ├── routers/          # Thin route handlers for app and auth APIs
│   │       ├── services/         # Recruitment domain business logic
│   │       └── lib/              # Shared server utilities
│   ├── auth/                     # Better Auth configuration
│   ├── db/                       # Drizzle database schema
│   ├── email/                    # React Email templates
│   └── common/                   # Shared types and validations

• Node.js 24+
• pnpm 10+
• Cloudflare account (for remote D1 / Workers deploy)

1. Clone the repository and install dependencies:

git clone <repository-url> x-hiring
cd x-hiring
pnpm install

2. Configure local Worker secrets:

cp apps/web/.dev.vars.example apps/web/.dev.vars

Edit apps/web/.dev.vars with your values (see Environment Variables below). For local TanStack Start + Cloudflare development, this is the preferred config source. apps/web/.env is now only a legacy fallback for plain Node-based tooling.

3. Configure D1 in apps/web/wrangler.toml:

• Local development uses the checked-in env.development D1 binding together with .wrangler/state.
• Before running against a real Cloudflare database, replace database_id with your actual D1 database ID.
• Keep the binding name as DB, because the app and auth layer resolve D1 from that binding.

4. Initialize the local D1 schema:

pnpm run db:generate
pnpm run db:migrate

Optional seed data:

pnpm run db:seed

db:seed will reset the local D1 sample tables before inserting fresh demo data.

Start the development server:

pnpm run dev

Visit http://localhost:3002

# Development
pnpm run dev          # Start all apps (runs local D1 migrations, then vite dev with CLOUDFLARE_ENV=development)
pnpm run dev:web      # Start web app only

# Type Checking
pnpm run check-types  # Check TypeScript types across all packages

# Code Quality
pnpm run check        # Vite+ / Oxlint checks
vp fmt                # Format with Oxfmt
vp lint --fix         # Auto-fix lint issues

# Database
pnpm run db:generate            # Generate migration files
pnpm run db:migrate             # Alias of local D1 migration
pnpm run db:migrate:local       # Apply migrations to local D1 (development env)
pnpm run db:migrate:remote      # Apply migrations to remote D1 (development env)
pnpm run db:migrate:production  # Apply migrations to production D1
pnpm run db:seed                # Reset and seed local D1 with sample data
pnpm run cf-typegen             # Generate Wrangler/Cloudflare runtime types from development env

• Use apps/web/.dev.vars for local Worker development with vite dev / Wrangler bindings.
• Keep non-secret runtime defaults in apps/web/wrangler.toml.
• apps/web/.env is only a fallback for plain Node-based tooling.
• In the Cloudflare runtime, server-side code reads Worker bindings/env first.
• Only variables prefixed with VITE_ are exposed to the browser. Never put secrets in VITE_ variables.

• D1 is configured through the DB binding in apps/web/wrangler.toml, not through DATABASE_URL.
• Local D1 state is persisted in apps/web/.wrangler/state after running migrations.
• Local development uses the development environment in Wrangler config.
• Replace the placeholder database_id values in Wrangler config before applying remote migrations or deploying.

• app.job.*: job listing, detail, related-job and RSS data services
• auth.*: authentication-related endpoints retained by the Worker API

pnpm run build

Build output is located at apps/web/dist/ (client/ for static assets, server/ for the server bundle).

This project is configured for Cloudflare Workers + D1 through the checked-in apps/web/wrangler.toml.

pnpm run build

1. Create real D1 databases in Cloudflare and set the database_id values in apps/web/wrangler.toml.
2. Apply the schema to the remote D1 database:

pnpm run db:migrate:production

3. Set production secrets with Wrangler, for example:

cd apps/web
wrangler secret put BETTER_AUTH_SECRET
wrangler secret put INGESTION_TRIGGER_SECRET

4. Deploy the app:

pnpm run deploy

Wrangler will deploy the Worker plus the built client assets from apps/web/dist/.

Apache License 2.0