添加geo监测功能，以及部分ai运维能力。

.claude/skills/laravel-architecture-guardian/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: laravel-architecture-guardian
+description: Use when writing, reviewing, or refactoring Laravel PHP code where architecture quality matters. Activate before modifying controllers, services, actions, jobs, models, requests, policies, AI agents, tools, or cross-module workflows. This skill prevents messy overgrown code by forcing context reading, responsibility boundaries, small Laravel-shaped designs, PHPDoc for every new function, tests, and quality gates. Pair with laravel-best-practices for Laravel API details, and with ai-sdk-development when touching the `Laravel\Ai\` namespace or project AI features.
+license: MIT
+metadata:
+  author: majin
+---
+
+# Laravel Architecture Guardian
+
+## Purpose
+
+Act like a senior Laravel architect who prevents accidental "big ball of mud" code. Your job is not to write more code; it is to make the smallest clear change that fits the existing application.
+
+## Required Companion Skills
+
+- Read `laravel-best-practices` before writing Laravel backend code.
+- Also read `ai-sdk-development` when the change touches `Laravel\Ai\`, AI agents, tools, prompts, structured output, provider calls, or conversation workflows.
+
+## Workflow
+
+1. Understand the request and the existing implementation before editing.
+2. Identify the owning layer: route, controller, request, action, service, job, model, policy, view, or config.
+3. Choose the smallest design that keeps each class responsible for one job.
+4. Decide the test level before coding: unit, feature, job, policy, command, or manual-only with a reason.
+5. State the implementation plan for non-trivial work before writing code.
+6. Write or update behavior-focused tests when the change has business logic, persistence, authorization, queues, external calls, or AI behavior.
+7. Add PHPDoc to every new PHP function or method, including return type meaning and array shapes when relevant.
+8. Run the relevant linter/test checks, or clearly report why they were not run.
+
+## Quality Gates
+
+Before finalizing any non-trivial implementation, refactor, or review, verify all of the following:
+
+- Nearby code was read before editing, not only the target file.
+- The behavior being changed can be summarized in one sentence.
+- The owning layer was identified and respected.
+- Controllers stay thin, dependencies are explicit, and views contain no business logic.
+- Every new PHP function or method has useful PHPDoc with domain meaning, array shape, and return shape when relevant.
+- Risky behavior is tested, or the reason for not testing is stated.
+- No method mixes validation, persistence, side effects, and response formatting.
+
+## Architecture Rules
+
+- Keep controllers thin. Validation belongs in Form Requests; business workflows belong in actions or services.
+- Do not hide dependencies behind `app()`, `resolve()`, facades, or singletons when constructor injection is practical.
+- Prefer explicit data flow over magic mutation of request arrays, model attributes, or global state.
+- Do not introduce a new abstraction unless it removes real duplication or protects a real boundary.
+- Keep database queries out of Blade templates and avoid business decisions in views.
+- Preserve the codebase's existing conventions unless they are the direct source of the problem.
+- Prefer deleting or replacing unshipped branch code over adding compatibility shims around it.
+- For AI SDK code, keep prompts, tool definitions, handlers, and persistence separate. Do not let AI tools mutate broad application state without a narrow handler and authorization check. Use structured output when downstream PHP depends on fields, and fake AI calls in tests.
+
+## Anti-Mess Gate
+
+Before finalizing code, reject your own change if any of these are true:
+
+- A method now handles validation, persistence, side effects, and response formatting at once.
+- A class name no longer describes its single responsibility.
+- The code needs a long explanation to justify its shape.
+- New behavior is not covered by tests and is risky to verify manually.
+- Arrays cross boundaries without documented shape or a clear DTO/value object convention.
+- Error handling swallows context or returns vague failure messages.
+- The implementation copied a pattern without checking nearby project code.
+
+## Output Format
+
+For non-trivial implementation, refactor, or review tasks, structure the response around:
+
+1. Architecture Decision - what layer owns the change and why.
+2. Implementation Plan - the smallest coherent steps; prefer 1-3 items, or staged work for larger tasks.
+3. Code Changes or Review Findings - what changed, or findings ordered by severity for reviews.
+4. Verification Result - quality gates passed, tests or lints run, and any remaining risk.
+
+## Deeper Guidance
+
+Use `references/engineering-gates.md` for the practical checklist before edits, during implementation, and before final response.
+
+Use `reports/existing-skill-assessment.md` for the evaluation that explains why this skill complements rather than replaces the existing Laravel and AI SDK skills.

.claude/skills/laravel-architecture-guardian/agents/interface.yaml

@@ -0,0 +1,35 @@
+name: laravel-architecture-guardian
+version: 1
+summary: Prevent messy Laravel PHP implementations by enforcing architecture boundaries, PHPDoc, tests, and quality gates.
+triggers:
+  - writing Laravel PHP backend code
+  - reviewing Laravel PHP backend code
+  - refactoring controllers, services, actions, jobs, models, requests, policies, or AI tools
+  - preventing overgrown methods, vague services, hidden dependencies, or untested business logic
+inputs:
+  required:
+    - user_request
+    - target_files_or_feature
+  optional:
+    - existing_patterns
+    - risk_level
+    - test_command
+outputs:
+  - architecture_decision
+  - implementation_plan
+  - code_changes_or_review_findings
+  - verification_result
+quality_gates:
+  - read nearby code before editing
+  - choose one owning layer for the change
+  - keep controllers thin and dependencies explicit
+  - add PHPDoc to every new PHP function or method
+  - test risky behavior or state why it cannot be tested now
+  - reject mixed-responsibility methods before finalizing
+companion_skills:
+  - laravel-best-practices
+  - ai-sdk-development
+exclusions:
+  - generic PHP style advice outside Laravel projects
+  - frontend-only Blade or Tailwind visual design work
+  - AI SDK syntax lookup without Laravel architecture decisions

.claude/skills/laravel-architecture-guardian/references/engineering-gates.md

@@ -0,0 +1,66 @@
+# Engineering Gates
+
+Use these gates when building or reviewing Laravel PHP code. They are intentionally concrete because vague "best practices" are easy for an AI agent to ignore.
+
+## Before Editing
+
+- Read the closest existing implementation, not only the target file.
+- Name the behavior being changed in one sentence.
+- Identify the owning layer and keep the change inside that boundary when possible.
+- Check whether validation, authorization, persistence, side effects, and presentation already have local patterns.
+- Decide the test level before coding: unit, feature, job, policy, command, or manual-only with a reason.
+
+## Design Gate
+
+A proposed design is acceptable only if it passes all of these checks:
+
+- Each new class has one reason to change.
+- Each new public method has an obvious caller and clear return contract.
+- Dependencies are injected unless the project has a stronger local convention.
+- Long procedural branches are split by domain meaning, not by arbitrary helper extraction.
+- Database writes, queued side effects, external API calls, and AI calls have explicit failure behavior.
+- User-facing strings, config values, and permissions are not hardcoded in business logic when the project already has a home for them.
+
+## PHPDoc Gate
+
+Every new PHP function or method must have a useful PHPDoc block.
+
+Good PHPDoc should include:
+
+- What the method does in domain terms.
+- Important parameter shape for arrays, collections, DTO-like payloads, or callable arguments.
+- Return shape or side effect when the native return type is not enough.
+- Thrown exceptions only when they are part of the expected contract.
+
+Avoid PHPDoc that repeats the method name or says nothing beyond the type hints.
+
+## Laravel Layering Defaults
+
+- Controller: HTTP orchestration only.
+- Form Request: validation and authorization for request input.
+- Action: one business operation with an `execute()` method when the project already uses that style.
+- Service: cohesive domain capability used by multiple operations.
+- Job: retryable or asynchronous work with explicit timeout, tries, and failure behavior when needed.
+- Model: relationships, casts, scopes, accessors, and persistence-adjacent behavior.
+- Policy/Gate: authorization decisions.
+- View/Blade: presentation only; no queries or business workflow.
+
+## AI SDK Specific Gate
+
+When touching Laravel AI code:
+
+- Keep prompt instructions, tool definitions, action handlers, and persistence separate.
+- Do not let an AI tool mutate broad application state without a narrow handler and authorization check.
+- Use structured output when downstream PHP code depends on fields.
+- Fake AI calls in tests and prevent stray prompts where practical.
+- Document any tool input/output array shape in PHPDoc.
+
+## Final Review
+
+Before final response, check:
+
+- The smallest coherent change was made.
+- No unrelated refactor slipped in.
+- Tests or lints were run, or the reason is stated.
+- Risky behavior has a verification path.
+- New PHP functions have useful PHPDoc.

.claude/skills/laravel-architecture-guardian/reports/existing-skill-assessment.md

@@ -0,0 +1,53 @@
+# Existing Skill Assessment
+
+## Evaluated Skills
+
+- `laravel-best-practices`
+- `ai-sdk-development`
+
+## Finding
+
+The existing skills are useful, but they do not fully solve the user's stated problem: AI generating messy Laravel PHP code that needs stronger architectural guidance.
+
+## `laravel-best-practices`
+
+This skill already covers many correct Laravel rules:
+
+- consistency with nearby code
+- database performance and N+1 prevention
+- validation, security, routing, controllers, migrations, queues, Blade, and testing
+- basic architecture rules such as thin controllers, actions, dependency injection, and Laravel conventions
+
+Its limitation is that it reads like a reference checklist. It does not strongly force the agent to:
+
+- decide ownership boundaries before editing
+- reject overgrown methods and mixed responsibilities
+- require a plan before non-trivial implementation
+- enforce PHPDoc on every new function
+- define anti-mess gates that catch vague abstractions and procedural blobs
+- connect architecture decisions to verification and tests
+
+Conclusion: keep it as the Laravel technical rule source, but do not rely on it alone for architecture discipline.
+
+## `ai-sdk-development`
+
+This skill is focused on Laravel AI SDK usage:
+
+- correct namespace and package entry points
+- agents, tools, structured output, conversation memory, streaming, queueing, and fakes
+- provider support and common SDK pitfalls
+
+Its limitation is intentional: it teaches API usage, not general Laravel architecture. It does not decide where AI logic belongs in the project, how to isolate tool side effects, or how to prevent AI agent classes from becoming oversized orchestration objects.
+
+Conclusion: use it only when AI SDK code is involved, alongside a stronger architecture skill.
+
+## Recommendation
+
+Create a new companion skill rather than rewriting either existing skill.
+
+The new skill should act as a pre-implementation and review guardrail:
+
+- load `laravel-best-practices` for Laravel details
+- load `ai-sdk-development` only for AI SDK work
+- force context reading, ownership boundaries, small class design, PHPDoc, tests, and final quality gates
+- explicitly reject "big ball of mud" patterns before code is finalized

.env.example

@@ -32,6 +32,10 @@ GEOFLOW_TITLE_AI_KEYWORD_SAMPLE_LIMIT=10
 GEOFLOW_DEBUG_KNOWLEDGE_QUERY_EMBEDDING=false
 # URL 智能采集 SSRF 防护默认严格；仅在明确受控的透明代理/Docker/VPN 混合 DNS 环境中开启。
 URL_IMPORT_ALLOW_MIXED_DNS=false
+# URL 智能采集单步骤 Job 最大执行秒数；Redis retry_after 应大于该值，默认 900。
+URL_IMPORT_QUEUE_TIMEOUT=900
+# 非空时投递到该队列名（需在 Horizon/supervisor 中监听）；留空用默认队列。
+#URL_IMPORT_QUEUE=imports
 # 后端 AI/Gemini 等出站 HTTP 代理；Docker 中访问宿主机代理请使用 host.docker.internal，而不是 127.0.0.1。
 # 默认只有 AI/Embedding 供应商域名走代理，避免 WordPress REST 和目标站 Agent 通信被代理截获；需要全局代理时设为 *。
 # GEOFLOW_HTTP_PROXY=http://host.docker.internal:9999
@@ -118,9 +122,12 @@ REVERB_BROADCAST_PORT=8080
 REVERB_BROADCAST_SCHEME=http
 REVERB_SERVER_HOST=0.0.0.0
 REVERB_SERVER_PORT=8080
+REVERB_SERVER_PATH=/reverb
 FILESYSTEM_DISK=local
 # 生产与计划一致用 redis；本机未装 Redis 时可改为 sync 或 database
 QUEUE_CONNECTION=redis
+# AI 运维流式：GET EventSource 单连接上限（秒），默认 900。
+#GEOFLOW_ADMIN_AI_OPS_CHAT_STREAM_MAX_SECONDS=1200
 
 CACHE_STORE=database
 # CACHE_PREFIX=
@@ -150,18 +157,65 @@ AWS_BUCKET=
 AWS_USE_PATH_STYLE_ENDPOINT=false
 
 VITE_APP_NAME="${APP_NAME}"
+# Reverb 配置同时给前端 Echo（Vite 编译时读取，必须保持与上面 REVERB_* 同步）
+VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
+VITE_REVERB_HOST="${REVERB_HOST}"
+VITE_REVERB_PORT="${REVERB_PORT}"
+VITE_REVERB_SCHEME="${REVERB_SCHEME}"
+VITE_REVERB_PATH="${REVERB_SERVER_PATH}"
+
+# --- GEO 引用监测（Python sidecar，见 tools/geo-monitor-poc/docs/SIDECAR_API.md）---
+# 运行模式：headless_linux（生产服务器+noVNC）| headed_desktop（macOS/Windows/有头Linux 本地维护）
+# Docker 内 sidecar（--profile geo-monitor）：http://geo-monitor-sidecar:8765
+# 宿主机 sidecar / Mac 有头模式：http://127.0.0.1:8765 或 http://host.docker.internal:8765
+GEOFLOW_GEO_MONITOR_RUNTIME=headless_linux
+GEOFLOW_GEO_MONITOR_ENABLED=false
+GEOFLOW_GEO_MONITOR_SIDECAR_URL=http://geo-monitor-sidecar:8765
+GEOFLOW_GEO_MONITOR_SIDECAR_TOKEN=
+GEOFLOW_GEO_MONITOR_PROBE_TIMEOUT=150
+GEOFLOW_GEO_MONITOR_EVIDENCE_DISK=local
+GEOFLOW_GEO_MONITOR_EVIDENCE_PREFIX=geo-monitor/evidence
+# sidecar 证据根目录（与 Laravel storage 共用，Docker 挂载 ./storage）
+GEOFLOW_GEO_MONITOR_EVIDENCE_ROOT=storage/app/geo-monitor/evidence
+# 资源池调度：账号串行锁缓存驱动（建议 redis）与锁 TTL（秒）
+GEOFLOW_GEO_MONITOR_LOCK_CACHE_STORE=redis
+GEOFLOW_GEO_MONITOR_ACCOUNT_LOCK_SECONDS=300
+# 风控回写：验证码冷却、连续失败冷却与阈值
+GEOFLOW_GEO_MONITOR_CAPTCHA_COOLDOWN_MINUTES=120
+GEOFLOW_GEO_MONITOR_FAILURE_COOLDOWN_MINUTES=30
+GEOFLOW_GEO_MONITOR_FAILURES_BEFORE_COOLDOWN=3
+# noVNC 运维（默认 127.0.0.1 + SSH 隧道；公网模式见下方）
+GEOFLOW_GEO_MONITOR_NOVNC_ENABLED=true
+GEOFLOW_GEO_MONITOR_POC_ROOT=tools/geo-monitor-poc
+GEOFLOW_GEO_MONITOR_NOVNC_BIND=127.0.0.1
+GEOFLOW_GEO_MONITOR_NOVNC_PORT=6080
+GEOFLOW_GEO_MONITOR_DISPLAY=:99
+# 后台维护页 SSH 隧道示例中的主机，例如 deploy@your-server
+GEOFLOW_GEO_MONITOR_SSH_HOST=
+# 公网远程桌面（经 Nginx /geo-monitor/novnc/ 反代，须 HTTPS + 鉴权；无需 SSH 隧道）
+GEOFLOW_GEO_MONITOR_NOVNC_PUBLIC_ENABLED=false
+GEOFLOW_GEO_MONITOR_NOVNC_PUBLIC_PATH=/geo-monitor/novnc
+# admin_session | basic | both（both = 后台已登录 或 专用账号密码 二选一）
+GEOFLOW_GEO_MONITOR_NOVNC_AUTH_MODE=admin_session
+GEOFLOW_GEO_MONITOR_NOVNC_BASIC_USER=
+GEOFLOW_GEO_MONITOR_NOVNC_BASIC_PASSWORD=
+GEOFLOW_GEO_MONITOR_NOVNC_UPSTREAM=geo-monitor-sidecar:6080
+
+# sidecar Docker 构建 pip 镜像（默认阿里云；与 docker-compose geo-monitor profile 一致）
+GEO_MONITOR_PIP_INDEX_URL=https://mirrors.aliyun.com/pypi/simple/
+GEO_MONITOR_PIP_TRUSTED_HOST=mirrors.aliyun.com
 
 # --- Docker 入口 geoflow-entrypoint（docker-compose 启动 app/queue 等时）---
 # 每次启动执行 composer install（拉代码后依赖变更；设为 false 可加快本地反复重启）
 COMPOSER_ON_START=true
-# Docker 构建和启动期 composer install 使用的 Packagist 镜像；留空可恢复官方源。
-COMPOSER_PACKAGIST_MIRROR=https://mirrors.aliyun.com/composer/
+# Docker 启动期 Composer Packagist 镜像（可选）；留空使用官方 https://repo.packagist.org
+# COMPOSER_PACKAGIST_MIRROR=
 # Docker 基础镜像可按网络情况切换为镜像代理地址，例如 m.daocloud.io/docker.io/library/php:8.4-cli-bookworm。
 PHP_CLI_IMAGE=php:8.4-cli-bookworm
 PGVECTOR_IMAGE=pgvector/pgvector:pg16
 REDIS_IMAGE=redis:7-alpine
-# 每次启动执行 php artisan migrate --force（数据库结构随仓库更新；设为 false 需自行迁移）
-AUTO_MIGRATE=true
+# 每次启动执行 php artisan migrate --force；默认 false，compose init 服务会显式开启。
+AUTO_MIGRATE=false
 # compose 的 init 服务专用：全新库时 migrate + seed 一次
 # AUTO_INIT_ONCE=true
 # 每次启动执行 db:seed（危险，默认关）