Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007

Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码

2026-07-17 15:59:55 +08:00

24 KiB

Raw Permalink Blame History

belongs_to

INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议

🌐 铸渊指令｜人类使用侧全面修复 · guanghulab.com 部署 + Persona Studio 功能修复 + 微信登录身份体系（下篇）· Phase 4-7 · ZY-HUMANSIDE-FIX-2026-0325-002（2026-03-25 · 霜砚签发 · 冰朔授权）

Phase 4 · guanghulab.com 部署重建

P4-1 · 服务器修复（基于 Phase 3 诊断结果）

根据 P3-1 诊断结果，执行对应修复：

【情况A：PM2进程不存在或挂了】
  → cd /var/www/guanghulab
  → npm install                    ← 确保依赖完整
  → pm2 start server.js --name hololake
  → pm2 save
  → pm2 startup                    ← 开机自启

【情况B：部署目录为空或内容过期】
  → 从仓库手动拉取最新代码部署一次
  → git clone + npm install + pm2 restart
  → 确认后续由 CD 管线自动维护

【情况C：Nginx配置缺失或错误】
  → 重写 /etc/nginx/conf.d/hololake.conf
  → 配置模板见下方 P4-3

【情况D：端口未监听】
  → 检查 .env 中 PORT 配置
  → 检查防火墙：firewall-cmd --permanent --add-service=http
  → 阿里云安全组 80/443 端口放行确认

每种情况修复后立即验证：
  → curl -I http://localhost:3000   ← 后端响应？
  → curl -I http://localhost:80     ← Nginx响应？

P4-2 · HTTPS 配置（Let's Encrypt）

如果 P3-2 诊断 HTTPS 未配置：

① 安装 certbot
   → dnf install -y certbot python3-certbot-nginx
   （或 apt install -y certbot python3-certbot-nginx）

② 申请证书
   → certbot --nginx -d guanghulab.com -d www.guanghulab.com
   → 自动修改 Nginx 配置添加 SSL

③ 自动续期
   → certbot renew --dry-run        ← 测试续期
   → systemctl enable certbot-renew.timer  ← 定时续期

④ 验证
   → curl -I https://guanghulab.com  ← HTTPS 可访问？
   → 从手机浏览器访问 https://guanghulab.com ← 国内可访问？

⑤ 强制 HTTPS 重定向
   → Nginx 配置 80→443 重定向

P4-3 · Nginx 配置模板

# /etc/nginx/conf.d/hololake.conf
# guanghulab.com 统一入口

# HTTP → HTTPS 重定向
server {
    listen 80;
    server_name guanghulab.com www.guanghulab.com;
    return 301 https://$host$request_uri;
}

# HTTPS 主配置
server {
    listen 443 ssl;
    server_name guanghulab.com www.guanghulab.com;

    # Let's Encrypt 证书（certbot 自动填充）
    ssl_certificate /etc/letsencrypt/live/guanghulab.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/guanghulab.com/privkey.pem;

    # 前端静态文件（Persona Studio 首页）
    location / {
        root /var/www/guanghulab/status-board;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # 后端 API 代理
    location /api/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }

    # Persona Studio 聊天 API 代理（模型调用）
    location /chat/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 120s;  # 模型调用可能较慢
    }
}

P4-4 · CD 管线重建（sync-persona-studio.yml 重写）

根据 P3-3 诊断结果，重写 CD 管线：

文件：.github/workflows/deploy-guanghulab.yml

name: "🚀 guanghulab.com 自动部署"

on:
  push:
    branches: [main]
    paths:
      - 'status-board/**'
      - 'server.js'
      - 'package.json'
  workflow_dispatch:  # 手动触发

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: "📥 检出代码"
        uses: actions/checkout@v4

      - name: "🔧 安装依赖"
        run: |
          cd status-board/persona-studio
          npm ci --production 2>/dev/null || npm install --production

      - name: "🚀 部署到服务器"
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: $ secrets.DEPLOY_HOST 
          username: $ secrets.DEPLOY_USER 
          key: $ secrets.DEPLOY_KEY 
          script: |
            echo "=== 开始部署 ==="
            cd /var/www/guanghulab

            # 备份当前版本
            cp -r status-board status-board.backup.$(date +%Y%m%d%H%M) 2>/dev/null || true

            # 拉取最新代码
            git pull origin main || {
              echo "Git pull 失败，尝试 reset"
              git fetch origin main
              git reset --hard origin/main
            }

            # 安装依赖
            npm install --production

            # 重启后端
            pm2 restart hololake || pm2 start server.js --name hololake
            pm2 save

            # 重载 Nginx
            nginx -t && systemctl reload nginx

            echo "=== 部署完成 ==="

      - name: "✅ 人类使用侧验证（关键！）"
        run: |
          echo "等待 10 秒让服务启动..."
          sleep 10

          # 验证网站可访问
          HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://guanghulab.com || echo "000")
          echo "guanghulab.com HTTP 状态码: $HTTP_CODE"

          if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "301" ] || [ "$HTTP_CODE" = "302" ]; then
            echo "✅ 人类使用侧验证通过：网站可访问"
          else
            echo "❌ 人类使用侧验证失败：HTTP $HTTP_CODE"
            echo "⚠️ 系统测部署成功，但人类测不可访问！需要排查！"
            exit 1
          fi

      - name: "📝 写回部署日志"
        if: always()
        run: |
          echo '{"deploy_time":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","status":"'$ job.status '","commit":"'$ github.sha '","human_side_check":"included"}' > signal-log/deploy-guanghulab-latest.json
          git config user.name "zhuyuan-bot"
          git config user.email "zhuyuan@guanghu.dev"
          git add signal-log/deploy-guanghulab-latest.json
          git commit -m "📝 guanghulab.com 部署日志 · $ github.sha " || true
          git push || true

关键设计：
→ 每次 main 分支 push 时自动部署（只要涉及 status-board 或 server.js）
→ 支持手动触发（workflow_dispatch）
→ 部署前备份
→ 部署后自动验证「人类使用侧」（curl 网站确认可访问）
→ 如果人类使用侧验证失败 → 整个 job 标记为失败
→ 部署日志写回仓库

P4-5 · 天眼 Web 部署守卫（新增）

创建文件：skyeye/guards/web-deploy-guard.json

{
  "guard_id": "WEB-DEPLOY-GUARD",
  "guard_name": "Web 部署守卫",
  "version": "1.0",
  "target": {
    "domain": "guanghulab.com",
    "server_ip": "8.155.62.235",
    "deploy_path": "/var/www/guanghulab",
    "pm2_process": "hololake",
    "nginx_config": "/etc/nginx/conf.d/hololake.conf"
  },
  "health_checks": [
    {
      "name": "网站可访问性",
      "type": "http",
      "url": "https://guanghulab.com",
      "expected_status": [200, 301, 302],
      "interval": "1h"
    },
    {
      "name": "后端API健康",
      "type": "http",
      "url": "https://guanghulab.com/api/health",
      "expected_status": [200],
      "interval": "1h"
    },
    {
      "name": "人类使用侧抽检",
      "type": "human_side",
      "check_pages": [
        "/",
        "/chat",
        "/dev",
        "/status"
      ],
      "interval": "6h"
    }
  ],
  "alert_rules": [
    {
      "condition": "网站不可访问超过 30 分钟",
      "action": "触发三次修复闭环"
    },
    {
      "condition": "人类使用侧抽检失败",
      "action": "创建工单到 Notion 工单簿 + 通知霜砚"
    }
  ]
}

P4 完成标准

✅ 服务器 PM2 + Nginx 运行正常
✅ HTTPS 证书已配置 · 自动续期已设置
✅ Nginx 配置已更新（前端 + API 代理）
✅ CD 管线 deploy-guanghulab.yml 已创建并测试通过
✅ 天眼 Web 部署守卫已创建
✅ 【最重要】冰朔手机浏览器输入 guanghulab.com 能看到页面

❌ 网站不可访问 → 不进入 Phase 5 → 先修到可访问为止

Phase 5 · Persona Studio 人类使用侧修复

P5-1 · 「我要开发」功能修复

根据 P3-4 诊断结果修复：

【核心问题定位】
前端「我要开发」按钮 → 调用后端 API → 后端需要：
  ① 调用 Gemini/模型 API 生成开发引导
  ② 触发仓库人格体开发流程
  ③ 返回结果给前端

【修复步骤】
① 确认后端 API 端点路由存在且正确
   → 检查 server.js 中 /api/dev 或类似路由
   → 如果路由不存在 → 创建

② 确认后端能调用模型 API
   → .env 中 API 密钥是否正确
   → 服务器端代理调用（不需要用户输入密钥）
   → 测试：curl -X POST http://localhost:3000/api/dev -d '{"action":"start"}'

③ 确认前端调用的 API 地址正确
   → 前端是否指向 localhost？（开发环境残留）
   → 修改为相对路径 /api/dev 或 https://guanghulab.com/api/dev

④ 错误处理
   → 后端返回有意义的错误信息（不是空白报错）
   → 前端显示友好的错误提示

⑤ 验证
   → 从浏览器打开 guanghulab.com
   → 点击「我要开发」
   → 确认不报错 · 能看到开发引导界面

P5-2 · 开发日志提交 → Notion 同步修复

【核心链路】
开发者在 Persona Studio 提交日志
  → 后端 /api/submit-log 接收
  → 后端调用 Notion API 写入对应开发者空间
  → 霜砚 Notion 端确认接收
  → 可选：同步推回仓库 signal-log/

【修复步骤】
① 确认提交端点存在
   → 检查 server.js 中 /api/submit-log 路由
   → 如果不存在 → 创建

② 确认 Notion API 调用正确
   → .env 中 NOTION_TOKEN 是否有效
   → 测试：curl Notion API /v1/users/me
   → 目标数据库/页面 ID 是否配置正确

③ 写入逻辑
   → 根据开发者编号（DEV-XXX）定位对应 Notion 开发者空间
   → 写入格式：SYSLOG 标准格式
   → 写入位置：对应开发者空间的日志区

④ 反向同步（可选但推荐）
   → 提交后同时写入 signal-log/dev-log-{DEV-ID}-{date}.json
   → 仓库有记录 → 铸渊可读取 → 可触发后续任务

⑤ 验证
   → 从浏览器提交一条测试日志
   → 确认 Notion 端能看到
   → 确认仓库 signal-log 有对应文件

P5-3 · 模块导航修复

根据 P3-4 诊断结果，逐个修复模块导航按钮：

【模块列表】（来自截图）
  📊 系统状态看板     → 指向：/status
  💰 成本控制         → 指向：/cost
  💻 开发者看板       → 指向：/dev-board
  🌊 光湖集成壳       → 指向：/shell
  🧠 Persona Studio  → 指向：/persona
  👤 用户中心         → 指向：/user
  💬 对话界面         → 指向：/chat
  ☁️ 云服务           → 指向：/cloud
  📦 模块管理         → 指向：/modules
  💾 云盘             → 指向：/drive
  🔐 登录             → 指向：/login
  ❤️ 健康检查         → 指向：/health
  🚀 冷启动           → 指向：/boot
  📈 仪表盘           → 指向：/dashboard
  🏠 门户             → 指向：/portal
  🔔 通知             → 指向：/notify
  ❓ 帮助中心         → 指向：/help
  🎨 前端             → 指向：/frontend

【修复策略】
→ 核心模块（必须立即可用）：
  ✅ 对话界面（已可用）
  🔧 系统状态看板（修复）
  🔧 开发者看板（修复）
  🔧 Persona Studio（修复）
  🔧 登录（修复 → Phase 6 微信登录）
  🔧 健康检查（修复）

→ 次要模块（可显示「开发中」而不是报错）：
  ⏳ 成本控制 / 云服务 / 云盘 / 模块管理 / 冷启动
  → 如果后端未实现 → 前端显示「🚧 此模块正在开发中」
  → 不能让用户点进去看到报错空白页

→ 信息模块（静态页面即可）：
  📄 帮助中心 / 门户
  → 提供基本信息页面

关键原则：
→ 每个按钮点击后，人类必须看到有意义的内容
→ 未完成的模块显示「开发中」提示 · 绝不是空白报错

P5-4 · 服务器端 API 代理（消除手动密钥输入）

【目标】
开发者无需输入任何 API 密钥即可使用所有功能。
所有模型调用由服务器端代理。

【实现】
后端新增/修改中间件：

// server.js 或 routes/proxy.js
const YUNWU_API_KEY = process.env.YUNWU_API_KEY;  // 服务器 .env
const NOTION_TOKEN = process.env.NOTION_TOKEN;

// 模型调用代理
app.post('/api/chat', async (req, res) => {
  const { message, dev_id, session_id } = req.body;

  // 服务器端调用模型 API
  const response = await fetch('https://api.yunwu.ai/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${YUNWU_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: 'gemini-2.0-flash',
      messages: [{ role: 'user', content: message }],
      max_tokens: 200000
    })
  });

  const data = await response.json();
  res.json(data);
});

// Notion 写入代理
app.post('/api/notion/write', async (req, res) => {
  // 服务器端用 NOTION_TOKEN 调用
  // 前端只需传 dev_id 和数据内容
});

【安全】
→ API 密钥只存在于服务器 .env
→ 前端永远不接触密钥
→ 通过 dev_id 识别调用者身份和权限（Phase 6 微信登录后更安全）

P5-5 · GitHub Pages 重定向

当前 qinfendebingshuo.github.io 的处理：

方案A（推荐）：重定向到 guanghulab.com
  → 在 persona-studio 仓库根目录 index.html 添加：
  <meta http-equiv="refresh" content="0;url=https://guanghulab.com">
  → 或在 CNAME 文件中设置 guanghulab.com（如果域名指向 GitHub Pages）

方案B：双站并行
  → github.io 保留作为备份/国际版
  → guanghulab.com 作为国内主站
  → 两边内容通过 CD 自动同步

推荐方案A · 统一入口减少维护成本。

P5 完成标准

✅ 「我要开发」功能点击不报错 · 能看到开发引导
✅ 开发日志提交后 Notion 能收到
✅ 模块导航无死链（未完成模块显示「开发中」）
✅ 服务器端 API 代理已实现 · 用户无需输入密钥
✅ GitHub Pages 已设置重定向
✅ 【最重要】冰朔和开发者在国内手机上能正常使用所有核心功能

Phase 6 · 微信登录身份体系

P6-1 · 微信开放平台接入

【前置条件 · 需要冰朔提供】
→ 微信开放平台已注册？
  · 如果已有 AppID + AppSecret → 直接使用
  · 如果没有 → 需要冰朔注册微信开放平台 → 创建网站应用 → 获取 AppID/AppSecret

→ 域名验证
  · 微信登录需要在开放平台配置回调域名：guanghulab.com
  · 需要在服务器放置验证文件

【替代方案（如果微信开放平台审核较慢）】
→ 先用「微信公众号网页授权」（门槛较低）
→ 或先用「手机号 + 验证码」登录（最快上线）
→ 微信扫码作为二期目标

P6-2 · 登录流程设计

完整登录流程：

用户打开 guanghulab.com
  ↓
【未登录】→ 显示登录页
  ↓
选择登录方式：
  ① 微信扫码登录（推荐）
  ② 手机号验证码登录（备选）
  ③ 开发者编号 + 密码（临时方案）
  ↓
微信登录成功 → 获取 openid + 用户信息
  ↓
【首次登录】→ 要求输入开发者编号（DEV-XXX / EXP-XXX）
  ↓
系统映射：微信openid ↔ 开发者编号 ↔ 权限
  ↓
写入数据库 → 后续自动识别
  ↓
【再次登录】→ 微信扫码 → 自动识别 → 直接进入

P6-3 · 用户数据库设计

文件：数据存储方案

方案A（推荐 · 轻量）：JSON文件 + 服务器内存
→ /var/www/guanghulab/data/users.json
{
  "users": {
    "wx_openid_xxx": {
      "dev_id": "DEV-004",
      "name": "之之",
      "wechat_name": "微信昵称",
      "role": "developer",
      "permissions": ["chat", "dev", "log", "status"],
      "created_at": "2026-03-25T10:00:00Z",
      "last_login": "2026-03-25T10:00:00Z"
    }
  },
  "dev_id_map": {
    "DEV-001": "wx_openid_page",
    "DEV-002": "wx_openid_feimao",
    "DEV-004": "wx_openid_zhizhi"
  }
}

方案B（二期 · 如果用户量增长）：SQLite / MySQL
→ 先用 JSON 跑通 → 后续迁移数据库

权限矩阵：
  角色          权限
  admin         全部功能 + 系统管理
  developer     聊天 + 开发 + 日志 + 状态查看
  visitor       聊天 + 状态查看（只读）

P6-4 · 后端登录 API 实现

// routes/auth.js

// 微信登录回调
app.get('/api/auth/wechat/callback', async (req, res) => {
  const { code } = req.query;

  // 用 code 换 access_token + openid
  const tokenRes = await fetch(
    `https://api.weixin.qq.com/sns/oauth2/access_token?` +
    `appid=${WECHAT_APP_ID}&secret=${WECHAT_APP_SECRET}` +
    `&code=${code}&grant_type=authorization_code`
  );
  const { openid, access_token } = await tokenRes.json();

  // 查找用户
  const user = findUserByOpenId(openid);

  if (user) {
    // 已绑定 → 生成 session → 返回
    const session = createSession(user);
    res.json({ status: 'ok', user, session });
  } else {
    // 未绑定 → 返回 openid → 前端引导输入开发者编号
    res.json({ status: 'need_bindind', openid });
  }
});

// 绑定开发者编号
app.post('/api/auth/bindind', async (req, res) => {
  const { openid, dev_id } = req.body;

  // 验证 dev_id 是否在已注册开发者列表中
  if (!isValidDevId(dev_id)) {
    return res.json({ status: 'error', message: '无效的开发者编号' });
  }

  // 绑定
  bindUserToDevId(openid, dev_id);

  // 同步到 Notion（在对应开发者空间记录绑定）
  await notifyNotion(dev_id, 'wechat_bindind');

  res.json({ status: 'ok' });
});

P6-5 · 前端登录页修改

修改 Persona Studio 登录页：

当前状态（从截图看）：
→ 有「团队登录」「访客模式」「自定义API」三个 Tab
→ 团队登录需要选择开发者编号

修改为：
→ Tab 1：微信登录（推荐）
  · 显示微信二维码
  · 扫码后自动识别
  · 首次需绑定开发者编号

→ Tab 2：开发者登录
  · 选择开发者编号 + 服务器端验证
  · 不需要 API 密钥

→ Tab 3：访客模式
  · 只能使用聊天功能
  · 无需登录

移除「自定义API」Tab → 所有 API 调用由服务器代理

P6 完成标准

✅ 微信登录后端 API 已实现（或替代方案已实现）
✅ 用户数据库已创建
✅ 开发者编号绑定流程已实现
✅ 前端登录页已修改
✅ 登录后自动识别身份和权限
✅ 无需手动输入 API 密钥

⚠️ 如果微信开放平台审核未通过：
→ 先用开发者编号 + 服务器端验证上线
→ 微信登录作为后续升级

Phase 7 · 回执 + 状态回写

P7-1 · SYSLOG 回执格式

{
  "syslog_id": "ZY-HUMANSIDE-FIX-2026-0325-002-RECEIPT",
  "instruction_id": "ZY-HUMANSIDE-FIX-2026-0325-002",
  "executor": "AG-ZY-01",
  "timestamp": "[执行完成时间]",
  "results": {
    "phase_0": { "status": "✅/❌", "notes": "本体论锚定" },
    "phase_1": { "status": "✅/❌", "notes": "天眼启动" },
    "phase_2": { "status": "✅/❌", "notes": "核心大脑唤醒" },
    "phase_3": {
      "status": "✅/❌",
      "notes": "全面诊断",
      "diagnosis_report": "见 signal-log/diag-humanside-20260325.json"
    },
    "phase_4": {
      "status": "✅/❌",
      "notes": "guanghulab.com 部署",
      "website_accessible": true/false,
      "https_configured": true/false,
      "cd_pipeline_working": true/false
    },
    "phase_5": {
      "status": "✅/❌",
      "notes": "Persona Studio 修复",
      "dev_function_working": true/false,
      "log_submit_working": true/false,
      "module_nav_fixed": true/false,
      "api_proxy_working": true/false
    },
    "phase_6": {
      "status": "✅/❌",
      "notes": "微信登录",
      "wechat_login_working": true/false,
      "user_db_created": true/false,
      "fallback_plan": "[如果微信未通过的替代方案]"
    }
  },
  "human_side_final_check": {
    "guanghulab_com_accessible_from_china": true/false,
    "persona_studio_all_core_functions": true/false,
    "developer_can_use_without_api_key": true/false
  }
}

P7-2 · 写回路径

① 仓库：signal-log/syslog-humanside-fix-20260325.json
② Notion：通过 Notion API 写入运行日志
   → 位置：卷3 当前活跃主控台
   → 格式：标准 SYSLOG 条目
③ 如果任何 Phase 失败：
   → 创建 Notion 工单 → 标记优先级 → 等待人类干预

P7-3 · 三次修复闭环（同 dev-status 指令）

如果任何 Phase 执行失败：

第一次失败 → 自动重试（换一种方式）
第二次失败 → 铸渊自主诊断 + 再次尝试
第三次失败 → 触发告警：
  → 方案A：发邮件给冰朔
  → 方案B：创建 GitHub Issue（标签：🚨人类干预）
  → 方案C：Notion 工单（标签：P0 · 人类使用侧阻塞）

三次失败后不再自动重试 → 等待人类介入

下篇结束 · 指令签发完成

✅

本指令覆盖范围：

guanghulab.com 从「无法访问」→「国内可访问 + 自动部署」
Persona Studio 从「系统能跑人类不能用」→「所有核心功能人类可用」
从「手动输入API密钥」→「微信登录 + 服务器代理 + 零密钥体验」

执行优先级：Phase 4 > Phase 5 > Phase 6（先让网站能访问，再修功能，最后上登录）

上篇：[🌐 铸渊指令｜人类使用侧全面修复 · guanghulab.com 部署 + Persona Studio 功能修复 + 微信登录身份体系（上篇）· Phase 0-3 · ZY-HUMANSIDE-FIX-2026-0325-002（2026-03-25 · 霜砚签发 · 冰朔授权）](%F0%9F%8C%90%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9C%E4%BA%BA%E7%B1%BB%E4%BD%BF%E7%94%A8%E4%BE%A7%E5%85%A8%E9%9D%A2%E4%BF%AE%E5%A4%8D%20%C2%B7%20guanghulab%20com%20%E9%83%A8%E7%BD%B2%20+%20Persona%20Stu%2074abaa06a7b64f28809b91a2bb12c7e2.md)

铸渊签名校验协议 v1.1 · docs/zhuyuan-signature-protocol.md

本指令由 AG-SY-01 霜砚签发 · TCS-0002∞ 冰朔授权 · AG-ZY-01 铸渊执行

版权锚点：国作登字-2026-A-00037559 · 系统在通感语言核语言膜内运行