621acf12ef
- MEMORY.md 索引：xpcool.com 的描述由「主域名（品牌首页）」改为 「随机壁纸站（浏览器实时生成，可导出 4K；中英日韩 + 日夜主题）」。 - DEPLOY.md 站点表：同步 xpcool.com 一行的定位与产物体积， 并记上部署脚本改为 pack-xpcool.ps1 + deploy-xpcool.ps1 两步走。 - 2026-09-14 日志：追加本次改版的完整记录，含三处根因分析 （画面和泥、strata 层交叉、遮罩浓度过激）与两处真 bug。 顺带记录本次部署踩到的两个坑（已修进脚本，值得复用）： 1. 新写的 .ps1 必须带 UTF-8 BOM，否则本机 PowerShell 5.1 按 GBK 解码， 中文被截断导致解析失败 —— 用字节级前置 EF BB BF 修，不能用 Get-Content -Raw + Out-File（会不可逆地破坏中文）。 2. deploy-xpcool.ps1 在 $ErrorActionPreference='Stop' 下，ssh 回传的 nginx -t / openssl 正常输出走 stderr，被 PowerShell 当成终止性错误抛出， 于是「远端其实跑通了、本地却中途退出」，表现为配置已装但没 reload 的 半个部署。原生调用前后临时切回 Continue，成败只认 $LASTEXITCODE。
17 lines
7.2 KiB
Markdown
17 lines
7.2 KiB
Markdown
# 2026-09-14
|
||
|
||
2026-09-14 | REQ | **xpcool.com 方向重定：删掉刚上线的「GPU 实时生成的宇宙」，改为「随机壁纸站」**。用户七项要求：每次进入随机壁纸 / PC 横版手机竖版 / 可下载 / 可刷新 / 页脚显示备案号 / 中英日韩四语言 / 日夜主题切换，另要求 AI 补全未考虑项（已补：收藏与最近看过、分享链接带种子、分享卡片 og.png、快捷键、对比度自适应遮罩、导出多分辨率多维度的「按目标尺寸重绘」）
|
||
2026-09-14 | CHG | web 端架构：**壁纸由浏览器 Canvas 2D 实时算出，零素材请求**。选它的三个理由：①服务器 5M 带宽且同时承载 home/tool/file/git/service 多站，传图片必卡 ②素材版权风险 ③随机性放客户端才能每次进入都不同且不产生请求。产物 gzip 后约 60KB（宇宙方案约 170KB）
|
||
2026-09-14 | FIX | **根治「画面和泥」**：两种种子画出来都是一片发灰的米白。根因①色斑用 `lighter` 叠加，重叠处被加成白色；②配色板是「从 6 个无关色相随机取」，必然互相抵消。改法：**配色板重写为有序色阶 `ramp`（由近底色排到对比最强），风格一律按 0..1 比例取色**（新增 `sampleRamp`），五风格全部迁移；mesh 改回 `source-over`。改后五风格逐一截图确认：warm 渐变 / 粉色地层 / 暖色光带 / 冷色星图 / 蓝色丝理，全部成立
|
||
2026-09-14 | FIX | strata 层交叉会打乱色阶顺序（各层原用独立噪声，fbm 值域 0..1 只会整体上移，交叉条件是 `振幅 > 层间距`，而旧振幅 0.17 倍画高 > 层间距 0.10~0.15 倍画高）。**改为所有层共用同一条波形、只做上下平移**，振幅再大也不交叉，另叠每层独有的小碎边
|
||
2026-09-14 | FIX | 浅色主题遮罩浓度过高把深色壁纸上下糊白：目标合成亮度原取 0.72 ≈ WCAG 13:1（AAA 只需 7:1），属过度设计。**放宽到 0.52**（主文字仍约 9:1），并提高 `--ink-faint/--ink-soft` 补偿页脚。**用像素采样验证**（Node 内置 zlib 手写最小 PNG 解码器读截图像素列）：strata 底部亮度 180 → 127，色阶完整呈现
|
||
2026-09-14 | FIX | 修两处真 bug：①`App.vue` 快捷键守卫 `target?.closest(...)`——从 `document` 派发的按键事件 target 不是元素，抛 `closest is not a function`（CDP 控制台抓到两次）②`scripts/shoot.mjs` 的 `goto` 漏了 seed 形参，五张风格截图全落同一默认种子、看起来「五种风格长得一样」
|
||
2026-09-14 | DOC | 验收脚本升级：真 390px 视口（CDP `Emulation.setDeviceMetricsOverride`）+ **五风格全扫** + `SHOOT_OG=1` 产出 `public/og.png`；另写离线反查脚本复刻 `hashSeed`+`mulberry32` 抽取顺序，用来核对「某种子实际用的风格与配色」——顺带验证了「同一颗种子切主题时风格不变、只换配色」这条设计性质成立
|
||
2026-09-14 | DOC | 补齐 `E:\CentOS\deploy-xpcool\` 缺失的本地脚本：`pack-xpcool.ps1`（清旧产物→铺 dist→打 bundle，assets 带内容哈希必须先清目录）+ `deploy-xpcool.ps1`（上传→远程 deploy.sh→公网验证）；`deploy.sh` 头部一直引用的本地脚本此前从未落盘
|
||
2026-09-14 | DEP | xpcool.com 重新构建并部署上线（含 gzip 配置首次生效）；README、`public/og.png`、`index.html`（OG 标签 + 四语言运行时改写 lang/title/description）一并更新
|
||
2026-09-14 | FIX | **排查「Bark 告警推送没生效」—— 结论：服务端整条链路全部正常，问题不在这侧**。按三段定位法逐层验证：(1) 服务器告警脚本 `server-monitor.sh` cron 每 10 分钟正常执行，`/var/log/server-monitor.log` 通篇 `[OK]`，9-13 00:10 后无推送是因**去重逻辑生效且无新事件**（`/var/lib/server-monitor/` 状态文件持续更新，banned-ips 2 条已记录），不是故障；(2) 手动 POST 自检 `http://127.0.0.1:8081/<key>` 返回 `{"code":200,"message":"success"}`，公网入口 `https://service.xpcool.com/bark/<key>/` 也 200（nginx `/bark/` → `127.0.0.1:8081`，末尾斜杠剥离前缀，配置正确）；(3) 用临时监控（id=11，指向 `127.0.0.1:9`，`maxretries=0`）触发真实 DOWN，**Kuma 00:42:40 成功推送至 bark 且返回 200**，验证后自清理（监控恢复 9 个、关联 9 条）。bark 容器 `finab/bark-server` Up 10 天无 ERROR，`/data/bark/bark.db` 单设备 token 注册于 9-11 22:01。**待用户确认手机是否收到 00:41:30 与 00:42:40 两条测试推送** —— 服务端 200 仅代表已提交 APNs，不代表送达，若未收到则问题在 iOS 侧（通知权限/专注模式/device token 失效）
|
||
2026-09-14 | DOC | 发现 `uptime-kuma` 容器**未挂载 Bark 增强补丁**：`docker inspect` 只有 `/data/uptime-kuma -> /app/data` 一个挂载，且宿主机 `/data/uptime-kuma-patch/` 目录**不存在** —— 即 DEPLOY.md 里记的「补丁已备好待部署」实际从未落地（`deploy-bark-custom.ps1` 未成功执行）。容器 CreatedAt 为 9-13 16:56、19:27 重启过一次。补丁本身非故障项（不影响通知发送），但自定义图标/重要警告/角标这些增强效果目前不生效
|
||
2026-09-14 | DOC | 沉淀经验到 skill `uptime-kuma-sqlite-ops`：新增「告警不生效排查：先分三段」章节（① 有无事件触发 → ② 推送是否发出 → ③ 手机是否收到），新增两条 SSH 踩坑（回传 base64 的那条 ssh 不能夹带 `ls`/`echo`，否则 `base64 -d` 报 invalid input；`scp ... 2>&1 | grep -v 噪音 && ssh ...` 因 grep 无匹配返回 1 而短路），并新增可复用自检脚本 `scripts/kuma-bark-check.sh`（变量化容器名与通知 id，自带备份与自清理）
|
||
2026-09-14 | DEP | **Bark 通知增强补丁正式部署并端到端验证通过**（9-13 备好的补丁因沙箱拦截 SSH 一直未落地）。流程：逐个 scp 7 个文件（icon/down/up.png、bark.js、status.xpcool.com.conf、deploy-bark-custom.sh、kuma-bark-verify.sh）→ 远端执行部署脚本（备份 `docker inspect` 与 nginx conf → 素材落 `/data/www/bark-assets/` → 补丁落 `/data/uptime-kuma-patch/bark.js` 并做 `node --check` 语法门禁 → nginx reload → 重建容器带 `:ro` 挂载 → 校验 md5）。结果：补丁 md5 `98c586f988084b89e1b5452257442b08` 宿主机与容器内一致、挂载在（`RW=false`）、9 处定制标记；端到端验证（临时监控 id=12 触发真实 DOWN）时 Bark 日志收到完整定制参数 `icon=…/bark-assets/icon.png & level=critical & volume=5 & badge=auto & isArchive=1 & image=…/bark-assets/down.png`，对比部署前仅 `icon`(GitHub)+`group`+`sound` 三项；清理后监控恢复 9 个、关联 9 条、面板 302 正常。**部署包归档 `E:\CentOS\deploy-bark-custom\`（含 README）**
|
||
2026-09-14 | FIX | 修 `deploy-bark-custom.sh` 两处隐患：① 补丁语法检查失败原先只打印错误、仍继续重建容器 → 改为 `exit 1` 中止（语法错会让 Kuma 整个通知模块挂掉）；② 取图验证原先只看 HTTP 状态码，会被 Kuma SPA 的 `200 + index.html` 骗过（且 `nginx reload` 后旧 worker 仍在退出，请求会落到 `location /`）→ 改为 `sleep 3` + 校验 `content_type=image/png`。另 `sudo docker cp` 产生的 `/tmp/_bark_check.js` 属 root，`rm` 需加 `sudo`
|