[pull] master from BingZi-233:master

.claude/commands/git-bump.md

@@ -0,0 +1,24 @@
+---
+name: git-bump
+description: 一键版本升级并 git 提交
+category: Release
+tags: [version, git, release]
+---
+
+**一键版本升级**
+
+自动递增 patch 版本并提交。
+
+**立即执行以下操作，无需确认**:
+
+1. 读取 `package.json` 中的 `version` 字段
+2. 递增 patch 版本 (例: 1.20.0 → 1.20.1)
+3. 使用 Edit 工具更新 `package.json`
+4. 执行 `git add -A` 暂存所有变更
+5. 执行 `git diff --cached --stat` 查看暂存区的变更文件
+6. 根据变更内容生成 commit 消息:
+   - 如果只有 `package.json` 变更: `chore: bump version to <新版本>`
+   - 如果有其他文件变更: 分析变更内容，生成符合 Conventional Commits 规范的消息，并在末尾附加 `(v<新版本>)`
+7. 执行 `git commit -m "<生成的消息>"`
+8. 创建 tag: `git tag v<新版本>`
+9. 输出: `✓ 版本升级完成: <旧版本> → <新版本>，本地 tag v<新版本> 已创建`

.claude/commands/git-push.md

@@ -0,0 +1,16 @@
+---
+name: git-push
+description: 推送 commit 和 tag 到远程仓库
+category: Release
+tags: [git, push, release]
+---
+
+**推送到远程仓库**
+
+推送当前分支的 commit 和所有本地 tag 到远程。
+
+**立即执行以下操作，无需确认**:
+
+1. 执行: `git push`
+2. 执行: `git push --tags`
+3. 输出: `✓ 已推送 commit 和 tags 到远程仓库`

.claude/commands/openspec/apply.md

@@ -0,0 +1,23 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/archive.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/proposal.md

@@ -0,0 +1,28 @@
+---
+name: OpenSpec: Proposal
+description: Scaffold a new OpenSpec change and validate strictly.
+category: OpenSpec
+tags: [openspec, change]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

.dockerignore

@@ -0,0 +1,38 @@
+# Dependencies
+node_modules
+.pnpm-store
+
+# Build outputs
+.next
+out
+dist
+
+# Git
+.git
+.gitignore
+
+# IDE
+.idea
+.vscode
+*.swp
+*.swo
+
+# Environment (不应打包进镜像)
+.env
+.env.local
+.env.*.local
+
+# Misc
+*.log
+npm-debug.log*
+pnpm-debug.log*
+.DS_Store
+Thumbs.db
+
+# Test
+coverage
+.nyc_output
+
+# Cloudflare (与 Docker 无关)
+.wrangler
+.open-next

.env.example

@@ -0,0 +1,19 @@
+# Supabase 数据库配置
+SUPABASE_URL=https://your-project.supabase.co
+# Supabase 匿名访问Key
+SUPABASE_PUBLISHABLE_OR_ANON_KEY=your-public-or-anon-key
+# Service Role Key (服务端使用，绕过 RLS，切勿暴露到客户端)
+SUPABASE_SERVICE_ROLE_KEY=your-service-role-key
+
+# 数据库空间
+NODE_ENV=dev
+# 轮询间隔(秒)
+CHECK_POLL_INTERVAL_SECONDS=60
+# 节点身份(多节点部署时标识实例)
+CHECK_NODE_ID=local
+# 历史数据保留天数(范围 7-365)
+HISTORY_RETENTION_DAYS=30
+# 官方状态检查间隔
+OFFICIAL_STATUS_CHECK_INTERVAL_SECONDS=60
+# 最大请求并发数
+CHECK_CONCURRENCY=8

.github/workflows/docker.yml

@@ -0,0 +1,49 @@
+name: Build and Push Docker Image
+
+on:
+  push:
+    tags:
+      - 'v*'
+  workflow_dispatch:
+
+env:
+  REGISTRY: docker.io
+  IMAGE_NAME: bingzi233/check-cx
+
+jobs:
+  build-and-push:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to Docker Hub
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Extract metadata (tags, labels)
+        id: meta
+        uses: docker/metadata-action@v5
+        with:
+          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+          tags: |
+            type=semver,pattern={{version}}
+
+      - name: Build and push Docker image
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+          platforms: linux/amd64

.gitignore

@@ -1,41 +1,54 @@
-# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
-
-# dependencies
-/node_modules
-/.pnp
-.pnp.*
-.yarn/*
-!.yarn/patches
-!.yarn/plugins
-!.yarn/releases
-!.yarn/versions
-
-# testing
-/coverage
-
-# next.js
-/.next/
-/out/
-
-# production
-/build
-
-# misc
-.DS_Store
-*.pem
-
-# debug
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-.pnpm-debug.log*
-
-# env files (can opt-in for committing if needed)
-.env*
-
-# vercel
-.vercel
-
-# typescript
-*.tsbuildinfo
-next-env.d.ts
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+/.pnp
+.pnp.*
+.yarn/*
+!.yarn/patches
+!.yarn/plugins
+!.yarn/releases
+!.yarn/versions
+
+# testing
+/coverage
+
+# next.js
+/.next/
+/out/
+
+# production
+/build
+
+# misc
+.DS_Store
+*.pem
+
+# debug
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+.pnpm-debug.log*
+
+# env files (can opt-in for committing if needed)
+.env*
+!.env.example
+
+# vercel
+.vercel
+
+# typescript
+*.tsbuildinfo
+next-env.d.ts
+
+# IDEA
+.idea
+
+combined.log
+error.log
+
+.playwright-mcp
+.mcp.json
+
+# openspec
+openspec/changes/

AGENTS.md

@@ -0,0 +1,44 @@
+<!-- OPENSPEC:START -->
+# OpenSpec Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/openspec/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/openspec/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+Keep this managed block so 'openspec update' can refresh the instructions.
+
+<!-- OPENSPEC:END -->
+
+# Repository Guidelines
+
+## Project Structure & Module Organization
+- `app/` hosts the App Router surface; `page.tsx` hydrates dashboard data and `app/api/dashboard/route.ts` exposes the refresh endpoint.
+- `components/` contains interactive widgets such as `dashboard-view.tsx`, `status-timeline.tsx`, and shared primitives inside `components/ui/`.
+- `lib/` carries domain logic: `core/` for polling and state, `providers/` for OpenAI/Anthropic/Gemini adapters, `database/` plus `supabase/` for persistence helpers, `types/` for DTOs, and `utils/` for helpers like `cn`.
+- Keep assets in `public/`, and store schema or seed changes exclusively in `supabase/migrations/` so Supabase stays reproducible.
+
+## Build, Test, and Development Commands
+- `pnpm install` syncs dependencies; re-run whenever `pnpm-lock.yaml` changes.
+- `pnpm dev` launches the Next.js dev server configured via `.env`.
+- `pnpm build` compiles the production bundle, while `pnpm start` serves that output for local smoke tests.
+- `pnpm lint` runs the Next.js Core Web Vitals rule set (`eslint.config.mjs`); fix findings before pushing.
+
+## Coding Style & Naming Conventions
+Default to server components and add `"use client"` only when hooks or browser APIs are required. TypeScript files use two-space indentation, `const` bindings, and descriptive PascalCase component names (`DashboardView`). Sort imports Node → packages → `@/` aliases, avoiding long relative paths. Compose styling through Tailwind utility classes plus `clsx`/`tailwind-merge`, and move repeated variants into `components/ui/`.
+
+## Testing Guidelines
+Automated tests are not wired up yet, but new logic should ship with either Vitest/Jest specs named `*.spec.ts` or clearly documented manual steps. Target ≥80 % coverage on `lib/core` and provider modules; explain any exception in the PR description. Until a runner is introduced, validate by running `pnpm dev`, exercising dashboard refreshes, and replaying Supabase migrations against a staging project before promoting to production.
+
+## Commit & Pull Request Guidelines
+History follows Conventional Commits (`feat:`, `fix:`, `chore:`, `refactor:`). Keep each commit scoped to a single concern and include related SQL migrations or config edits together. Pull requests must describe the change, link issues, attach UI screenshots/GIFs when visuals move, list the commands executed (build/lint/test), and mention any Supabase migration IDs applied. Request review early for provider updates so credentials and rate limits get a second set of eyes.
+
+## Security & Configuration Tips
+Copy `.env.example`, fill in `SUPABASE_*` plus `CHECK_POLL_INTERVAL_SECONDS`, and never commit real keys. Provider credentials belong in the `check_configs` table—seed them with the SQL snippets in `.env.example` instead of plaintext env vars. Use the mock endpoint in `lib/providers/stream-check.ts` for latency tests and scrub client logs before sharing.