|
|
1ac8d2a0f2
|
docs: 修正过时端口(8080→18080)与 statusCheck 示例值
审计发现 README 三处过时：
- 快速开始示例 docker run -p 3003:8080（容器内 nginx 已是 18080）
- 遗留 portal-nginx 配置示例里 blog 上游仍写 8080
- 配置示例里 statusCheck: true（该项已按要求关闭，示例值应同步为 false 并注明原因）
|
2026-09-12 15:17:42 +08:00 |
|
|
|
16707bdfab
|
docs: 同步「常用服务」新机制（导航项点击计数）并补 nav-visit 接口
审计发现文档仍有旧描述，且新端点完全没写：
- README：分组注释/机制说明/系统分组警示/history-server 职责 仍写成泛指的"访问频次"，
容易让人以为常用服务来自浏览器历史。统一改为"导航项点击次数（nav-visits.json）"，
并明确两者数据源互相独立（常用服务不看浏览器历史）
- README 接口表 + AGENTS.md §4.2 补 POST /api/history/nav-visit 的可执行示例
- AGENTS.md 已知坑补一条：顺序不像"最常点的"时如何排查
|
2026-09-12 15:16:57 +08:00 |
|
|
|
b980ce6292
|
fix(build): 测试文件 import 改为块形式（os/filepath/testing）
main_test.go 原为单行 import "testing"，补 import 的替换锚点没命中，
导致 os/filepath 未导入、history-server 编译失败（承接上一提交的坏状态）。
本次改为块形式导入，go vet 与 go test 均通过。
|
2026-09-12 12:42:08 +08:00 |
|
|
|
6c34970f38
|
feat(nav): 导航项点击频次独立统计，常用服务据此取 top-5
用户指出：导航项的访问频率应当单独统计。此前「常用服务」的排序依据是浏览器
历史的 host 访问次数（把站外浏览混进来反推），并不等于"我常点哪个服务"。
- history-server 新增 POST /api/history/nav-visit（内部 /nav-visit）：
按 host 计数并落盘 data 卷的 nav-visits.json（临时文件 + rename 原子写），
随后立即 rebuild，使「常用服务」按新计数重排
- rebuildDashySections：候选访问量改为只认 nav-visits 计数，不再使用浏览器历史；
无任何点击数据时保持既有分组内容不动（不空转、不误清）
- web/navi.js：点击 http(s) 导航项时用 sendBeacon 异步上报（不阻塞跳转，失败静默）
- 测试：计数递增、落盘、文件生成
|
2026-09-12 12:41:24 +08:00 |
|
|
|
a9845f1fba
|
feat(nav): 常用服务改为纯访问频次 top-5，取消 Gitea 置顶
用户要求：不要固定置顶 Gitea，且每个服务都应归到准确描述其功能的分组里。
- history-server/main.go：删除「强制 Gitea/代码托管置顶」逻辑（含 isCodeHostVal
参与的首位组装），改为按访问频次取前 5；顶部说明同步更正
- 文档：README / AGENTS.md 里"（Gitea 置顶）"的描述改为"不置顶任何服务"
- 现场分组调整：新建「代码托管」分组并把 Gitea 归入（此前它只存在于
系统管理的 常用服务 里，等于没有功能归属）
go vet / go test 通过。
|
2026-09-12 12:27:35 +08:00 |
|
|
|
7c3054f14a
|
docs: 明确 常用服务/历史访问 是系统管理分组，禁止手工加条目
用户指出：常用服务应当是按访问频次自动排序取前五，不该手工塞条目。
我部署 it-tools 时正是这么错的（把新项直接写进了 常用服务，污染频次榜）。
- AGENTS.md：写入导航条目示例前加警示（两个系统分组 + navSection 必须指向用户分组
+ 实测教训：塞进常用服务会被下次重建挤掉）
- README：配置接口章节加同样说明
现场已修正：IT Tools 移入「AI & 工具」，路由 navSection 同步改为该分组，
常用服务恢复为 4 项（系统按频次维护）。
|
2026-09-12 12:22:01 +08:00 |
|
|
|
e0e79c98da
|
docs(agents): 修正 /api/item 示例（嵌套形状）+ 补 /api/item/delete（DELETE + body）
实测发现手册里两处错误（部署 it-tools 时踩到）：
1. /api/item 是嵌套形状 {"sectionIndex":N,"item":{...}}，
扁平 {"name","url"} 会被拒绝并返回 "title and url required"
2. /api/item/delete 要求 **DELETE** 且 body 带 {"sectionIndex","itemIndex"}，
用 POST 会得到 "method not allowed"
同时补上"分组下标怎么取"的可执行片段，并写明：文档里的示例必须实测过，形状
不确定时先读 /api/schema 或源码里的处理函数。
|
2026-09-12 11:46:28 +08:00 |
|
|
|
890af22b95
|
fix(docs): 清除 AGENTS.md 里的真实令牌/口令/备案号（我自己写进去的），并修正端口写死
机械式 runbook 验证（照抄文档命令执行）抓到两个真问题：
1) 严重：AGENTS.md §6 脱敏自检把**真实令牌前缀、真实口令、真实备案号**当作
"示例模式"写了进去 —— 等于把凭据与备案信息提交进仓库。
改为特征检测（长度/字符集/格式），并排除文档自身；同时写明"不要用真实值当模式"。
2) §5 验收与 §4.3 验证把端口写死 3080：非默认端口部署（如 NAVI_ENTRY_PORT=13080）
照抄会全部得到 000（实测）。改为 PORT=${NAVI_ENTRY_PORT:-3080} 等变量，
并注明 NAVI_TLS=0 的部署没有跳转端口（该项 000 属预期）。
已知坑表补两条对应的现象与处理。
|
2026-09-12 11:17:05 +08:00 |
|
|
|
5ba7789e30
|
docs(readme): 架构描述改为当前实态（单容器即统一入口 + 内置认证）
README 开头与架构图还停留在"portal-nginx + portal-auth + navi"三容器时代。
- 开头一句话改为：反向代理 + 统一登录 + Dashy + SearXNG + 历史 + 管理后台
+ 路由管理全在同一容器内，容器自己就是入口（3080/8443，3081 跳转）
- 架构图重画：公网 → frps → frpc → navi 单容器，容器内按 $host 查路由表分流、
需要登录的走 auth_request 到内置登录服务(:3005)、未知域名给自定义 404、
上游故障给自定义 500（错误页免认证）
- 容器内部图补：nginx 内部端口 18080（对外 3080/8443）、/auth/verify 认证校验、
gateway/*.conf 路由生成来源
- 明确标注 portal-nginx / portal-auth 已停用，仅作回滚保留
|
2026-09-12 11:11:28 +08:00 |
|
|
|
02b321ab51
|
docs: 拆分双版本教程 —— AGENTS.md（agent 照着做）+ README.md（人类）
用户要求：教程要能让 agent 跟着做，且区分 agent 版与人类版。
新增 AGENTS.md（可机械执行，不做叙述）：
- §0 铁律 8 条（首装/升级不可混用、绝不重置门户口令、apply 后异步 reload、
/admin/api 前缀、路由表整表替换、脱敏清单、不 sed -i 单文件挂载、部署串行）
- §1 场景判定（一条命令区分首装/升级）
- §2 首装：前置检查、三组命令示例、**逐步期望输出**、5 条失败处置表
- §3 升级：硬性前提（旧容器无 cookie 域就必须传 NAVI_COOKIE_DOMAIN）、命令、
期望输出、收尾断言（含 navi-next 残留的处置）
- §4 配置：先取 /api/schema 清单，再给可直接照抄的六类写入命令 + **写完必须验证**
- §5 验收清单：五项探测及各自不符合时的含义
- §6 提交前脱敏清单（可执行命令 + 绝不可提交项 + "可配置项不得写死"）
- §7 回滚 §8 已知坑（8 条，全部是本次实测踩过的）
README：顶部加"两种读者两个入口"导航，并在首装/部署两节加指向 AGENTS.md 的指引。
|
2026-09-12 10:50:02 +08:00 |
|
|
|
412e51d1f5
|
docs: 教程同步本轮全部变更（升级守卫 / 可配置项 / agent 接口）
- 升级示例补 NAVI_COOKIE_DOMAIN、NAVI_HOME_URL：旧容器没有 cookie 域且未传时
脚本会拒绝升级（否则登录 cookie 退化 host-only，跨子域登录失效）
- 升级脚本环境变量表补齐：NAVI_COOKIE_DOMAIN / NAVI_HOME_URL / NAVI_CHECK_HOST /
NAVI_ROTATE_PORTAL_PASSWORD，并写明**默认不改登录口令**（生效凭据是数据卷里的加盐哈希，
改口令会让所有受保护域名立即要求新口令，属高风险，必须显式开启）
- 自定义文件表补 pages.go（文案渲染 + 卡片覆盖）与 schema.go（/api/schema 配置清单）
- 门户卡片章节补后台入口（站点信息 → 门户页服务卡片，与接口同一份数据）
- 自检域名说明：脚本内不写死任何域名，默认取路由表首条（避免脱敏改坏自检）
|
2026-09-12 10:47:41 +08:00 |
|
|
|
700775866a
|
fix(deploy): 修掉远端引号嵌套导致切换中途崩溃 + 补最终名字断言
真实事故：探测域名提取用了 `tr -d '"'"'"'` 这种引号嵌套，远端 bash 报
"unexpected EOF while looking for matching `'`"，脚本在"停旧容器→起新容器→
改名"的改名之前中断，容器留在 navi-next（服务正常但名字不对，
且验收里 docker inspect navi 全为空，看起来像数据丢失）。
修复：
- 改用无引号的字符类提取域名（grep -oE '[A-Za-z0-9][A-Za-z0-9.-]*\.[A-Za-z]{2,}'），
彻底避开引号嵌套
- 收尾加断言：docker inspect navi 必须成功；若发现仍在 navi-next，
明确提示可直接改名，而不是静默"成功"
现场已手动补齐：navi-next 完整核验（healthz/conf.yml/admin/schema 200、
入口 302/404/200/200/200、22 条路由、端口 3080/3081、门户标题与备案号完整、
env COOKIE_DOMAIN=1 明文 PASSWORD=0、数据卷凭据文件在）后改名为 navi，
回滚点 navi-prev-20260912104324(ui-v53) 保留。
|
2026-09-12 10:46:09 +08:00 |
|
|
|
b850a478fe
|
fix(deploy): 入口自检改为域名无关（脱敏把探测域名换成了占位符导致误判失败）
真实部署失败原因：脱敏时把仓库里所有 example.com 换成 example.com，连
deploy/zd-host.sh 的三个入口自检探测域名也一起换了 → 自检去探测
dashy.example.com（用户路由表里不存在）→ 404 → 判定失败并回滚。
修复：
- 探测域名默认取数据卷 gateway.yml 路由表第一条的 host（或 NAVI_CHECK_HOST 显式指定），
不再把任何具体域名写进脚本
- 已配置域名接受 200/302（门户 200、受保护 302 都算正常）；
000（未监听）/404（不在路由表）/5xx 才算失败；未知域名仍必须 404；3081 必须 302
- apply 后先轮询等待 reload 就绪再探测（异步 reload 会误判）
另修复上一轮引入的隐患：等待循环引用了脚本里不存在的 $CHECK_HOST/$ENTRY_PORT，
set -u 下会直接崩（与第一轮 HOST 未定义同类错误），本次一并纠正并改为先定义后使用。
|
2026-09-12 10:43:13 +08:00 |
|
|
|
dbdfe0faef
|
fix(deploy): 默认不改门户口令 + apply 后等待监听就绪
两个问题，都由本轮真实部署暴露：
1) 口令轮换不该默认执行
集成明文 env 清理时顺手加了"重置为强随机口令"，但重置会让所有受保护域名
（含用户访问 agent 界面的入口）立即要求新口令，用户若没读到日志就等于被锁在门外。
而生效凭据本是数据卷里的加盐哈希（/app/data/portal-auth.json），删掉明文 env
对登录毫无影响。→ 改为仅清理 env，轮换必须显式 NAVI_ROTATE_PORTAL_PASSWORD=1。
2) apply 触发的 nginx reload 是异步的
本次部署因此误判失败：受保护域名探测到 404（旧配置仍在生效），脚本判定
"应 302 实际 404" 并回滚。→ apply 之后、入口自检之前加入轮询等待就绪（最多 10s），
与 README「接口注意事项」第 4 条同一原因。
|
2026-09-12 10:42:44 +08:00 |
|
|
|
2eeaabb200
|
fix(deploy): NAVI_COOKIE_DOMAIN/NAVI_HOME_URL 未转发到远端，升级被自家守卫拦下
现象：本地已传 NAVI_COOKIE_DOMAIN=example.com，部署仍在远端报
"缺少 PORTAL_COOKIE_DOMAIN ... "（守卫在远端执行，而远端 heredoc 是引号形式，
不会展开本地变量）→ 升级被拦，生产保持 ui-v53 未变。
修复：在 ssh 命令行显式转发这两个变量（本地展开后作为远端环境变量传入）。
实测：远端能读到传入值。
|
2026-09-12 10:39:59 +08:00 |
|
|
|
ff4af5fa31
|
fix(deploy): 必填校验插在 HOST 赋值之前，set -u 下直接崩
现象：NAVI_HOST=... bash deploy/zd-host.sh v54 直接报
line 21: HOST: unbound variable 并退出（生产未受影响，纯脚本缺陷）。
原因：上一轮加 NAVI_HOST 必填校验时，把校验插到了 STAMP 之后、HOST 赋值之前，
而脚本是 set -u，提前引用未赋值变量即中止。
修复：校验移到 HOST 赋值之后；zd-host.sh 与 zd.sh 都改。
自测：不给 NAVI_HOST → 友好提示 + 退出码 2；给了则继续执行（实测进入构建阶段）。
|
2026-09-12 10:38:17 +08:00 |
|
|
|
203cd05fbb
|
docs: 接口注意事项（前缀 / 整表替换 / 必须 apply / reload 需等待）
验证过程中实际踩到的四点，写进 README 便于 agent 与人复用：
1. 管理接口前缀是 /admin/api；打根 /api/ 会拿到 200 + Dashy HTML 的假成功，
判断是否命中要看返回体类型而非状态码
2. 路由表是整表替换，必须提交完整 {routes:[...]}；清空非空表需 force:true
3. 改完必须 apply（内部 nginx -t 校验，失败保留旧配置并回显 nginx 报错）
4. apply 是异步 reload：立刻探测会得到旧结果（表现为'apply 了却 404'），
给出轮询等待入口就绪的示例脚本
|
2026-09-12 10:31:46 +08:00 |
|
|
|
bb41b61ad6
|
fix(gateway): 路由表接口只替换路由，不再整份配置重置（agent 友好）
真实验证（干净环境练兵）抓到：POST /admin/api/gateway/routes 会把整个
GatewayConfig 反序列化为零值后保存，因此
- 只提交单个路由对象 → {"routes":0,"status":"saved"}：**静默清空整张路由表**
- 提交 {"routes":[…] } → 其余字段被重置为默认（实测入口端口 13080 → 8081，
TLS/认证地址一并丢失），随后 apply 生成的配置与预期完全不符
对 agent 尤其危险：照文档提交一条路由就会改掉入口端口与所有其它路由。
修复：
- 只补路由表：以现有配置为基准，仅替换 Routes，其它字段原样保留
- 请求体必须是 {"routes":[...]}；缺该键 → 400 并说明正确形状（不再静默变空表）
- 非空表要清空必须显式传 force:true，否则 400 拒绝
- 测试：单个对象被拒；数组提交后 listenPort/TLS/认证地址/证书路径全部保留；
清空被拒、force 允许
- README：修正路由示例为完整数组形状，补"替换整张表"与 /admin/api 前缀说明
|
2026-09-12 10:28:03 +08:00 |
|
|
|
92fd32e7a9
|
feat(api): 全量配置项暴露为接口 + 后台增加门户卡片编辑框
用户要求：所有可配置项都应当是 API，方便 agent 直接把站点配成用户喜欢的样子。
- 新增 GET /api/schema：一次返回
· items：全部单值配置项（站点信息、登录页/门户页文案、备案号、页脚…），
含当前值、类型、写入口与请求体示例；**当前为空的键也会列出**，否则 agent 发现不了
· resources：结构化资源与其真正的写入口（导航、路由表+apply、门户卡片、壁纸、
门户口令、历史、图标上传、重载），并在 hint 里写明"路由表改完必须 apply"这类约束
- 后台「站点信息」新增「门户页服务卡片」编辑框：载入 / 保存 / 清空即回内置，
与 /api/portal-cards 同一份数据（界面能改的 agent 都能改）
- README 新增「配置接口（agent 可直接改）」：schema 用法、写入口对照表、可直接复制的示例
- 测试：schema 必须列出关键项与写入口；卡片接口写入生效、清空返回 reset 并回落内置
|
2026-09-12 10:19:22 +08:00 |
|
|
|
7c2bed2f2d
|
feat: 门户页卡片可配置 + 升级前域名校验 + 清理明文门户口令
按用户选择实施三件事：
1) 门户页服务卡片可配置（不再写死真实域名）
- portal/index.html 卡片区加 <!--NAVI_CARDS_START/END--> 标记，内置卡片改为通用示例
- renderPortalPage 支持数据卷 <data>/portal/cards.html 覆盖标记区间（清空即回落内置）
- 新增 GET/POST /api/portal-cards 读写该片段
- 测试：覆盖替换成功、空白片段回落内置
- 仓库内真实域名由此清零
2) 升级前必须提供跨子域单点登录变量（防止"去掉写死默认值"造成 SSO 静默失效）
- zd-host.sh 在切换前检查 PORTAL_COOKIE_DOMAIN：缺失且未传 NAVI_COOKIE_DOMAIN
时直接拒绝升级（退出码 2）并给出正确命令；PORTAL_HOME_URL 可用 NAVI_HOME_URL 补
- README 新增「升级已有部署前必须确认的两个变量」含失败表现与正确命令
3) 清理明文门户口令
- 迁移旧容器 env 时丢弃 PORTAL_PASSWORD（docker inspect 可见 = 泄露面）
- 升级后写入强随机口令并通过接口生效，部署日志只打印一次；失败不阻断升级并提示后台可改
|
2026-09-12 10:14:22 +08:00 |
|
|
|
b99319b38b
|
chore(sanitize): 备案号与域名一律可配置，仓库不再预置真实域名/备案号/内网地址
用户要求：备案号与域名都应当可配置，仓库内容要脱敏。
功能（不只是替换字面量）：
- 被代理页面注入的备案号改为读后台「站点信息」的 icp/gongan，**未配置就不注入**；
原先写死具体备案号，等于每个部署者都会把别人的备案信息印到自己页面上
- 注入内容做 nginx 安全处理（去引号/反斜杠/换行/美元符），并有测试覆盖
- auth.go：PORTAL_COOKIE_DOMAIN / PORTAL_HOME_URL 不再预置域名，
cookie 默认 host-only、首页默认相对路径 "/"
- gateway.go：默认 loginUrl 不再预置域名（受保护路由缺配置会明确报错，不静默生成跳不出去的登录页）
- 首装脚本在给了 NAVI_DOMAIN 时自动注入 PORTAL_COOKIE_DOMAIN/PORTAL_HOME_URL，
避免"去掉写死默认值"导致跨子域单点登录失效
脱敏：内网 IP（10.0.0.10）与真实备案号清零；真实域名仅剩门户页内容 8 处（待定）；
测试夹具/示例/错误页/脚本/后台占位提示全部通用化。
README：新增「跨子域单点登录需要的两个环境变量」；环境变量表改为 NAVI_HOST 必填。
测试：新增备案号注入三条（用配置、未配置不注入、危险字符清理）。
|
2026-09-12 10:10:52 +08:00 |
|
|
|
b01e49de49
|
fix(gateway): http→https 跳转是否带端口改为显式开关（避免生产回归）
练兵发现：跳转写成 return 302 https://$host$request_uri（不带端口），
非 443 端口的新装会跳到 443 打不开。
但直接用'端口 != 443 就带端口'推导会把生产弄坏：生产容器监听 3080，
对外经 frp 映射为 443，带端口会把公网用户导向 https://host:3080。
因此新增 gateway.yml 字段 redirectWithPort（默认 false，行为不变）：
- 默认：跳 https://host（前置 frp/443 的部署，含现生产）
- 全新安装且对外端口=入口端口：install-host.sh 自动置 true
测试补两条：开关为真时带端口、默认（生产形态）不带端口。
|
2026-09-12 09:52:20 +08:00 |
|
|
|
9612352bd1
|
fix(deploy): 首装 gateway.yml 字段名大小写错误导致 TLS 被静默忽略
TLS 练兵抓到（脚本自检 + 独立核对全挂，端口在监听但握手失败）：
生成的配置里三个 listen 13080 都没有 ssl、且没有 ssl_certificate，
说明 ListenHTTPS 一直是 false。
根因：GatewayConfig 的 yaml 标签是 listenHttps / listenTlsPort / authUrl /
loginUrl（大小写敏感），而脚本写的是 listenHTTPS / listenTLSPort / authURL /
loginURL → 被 YAML 静默忽略。后果严重：HTTPS 端口实际是明文，而跳转端口
又 302 到该端口，浏览器必然报错；authUrl/loginUrl 丢失还会让受保护路由
报'未配置认证地址'。
修复：字段名对齐 + apply 后断言 TLS=1 时配置必须含 ssl_certificate（失败即停），
避免同类字段名错误再次静默通过。
|
2026-09-12 09:46:18 +08:00 |
|
|
|
fe5ddf274b
|
feat(deploy): 首装脚本补 TLS 自检（跳转端口 302 / HTTP2 协商 / 证书可读）
TLS 是有证书用户的主路径，之前只在生产手工验过、脚本没覆盖。补上后
NAVI_TLS=1 的首装会自己验证：http 跳转端口是否 302 到 https、入口能否
协商 HTTP/2（对应曾踩过的 listen … ssl http2 写法）、证书是否能读出主题。
|
2026-09-12 09:45:13 +08:00 |
|
|
|
965c9cb41a
|
fix(deploy): code_of 定义提到等待循环之前（自检退出码 127）
第二次练兵：路由表路径修复生效（apply routes: 2），但因等待监听的循环
调用了尚未定义的 code_of，脚本以 127 退出。把函数定义移到首次调用之前。
|
2026-09-12 09:41:01 +08:00 |
|
|
|
158217103d
|
fix(deploy): 首装路由表路径写错（静默零路由）+ apply 空表安全阀
真实练兵（干净数据目录跑 install-host.sh）抓到：
1. 路由表源文件被写到 <数据卷>/gateway/gateway.yml，容器实际读取 <数据卷>/gateway.yml
→ apply 报 routes: 0，用户自备/生成的初始路由被静默忽略
2. 自检在 apply 后立即探测，nginx 还没 reload 完 → 误判连接失败；
code_of 失败时重复输出 000
3. 缺安全阀：路由表为空时 apply 会照常生成零路由配置并覆盖，
等于静默清空入口路由表
修复：
- install-host.sh 改写 <数据卷>/gateway.yml（并注释说明两个目录的区别）
- 自检前轮询等待入口监听就绪（最多 10s），code_of 只在成功时输出状态码
- handleGatewayApply 增加安全阀：路由表为空但现有配置含 server_name → 400 拒绝覆盖
- 新增测试 TestApplyRefusesEmptyRoutesOverExisting
|
2026-09-12 09:40:36 +08:00 |
|
|
|
c0cbdb5efc
|
feat(deploy): 补首装路径，使他人/AI 可照教程从零部署
审计发现 5 处断点（3 处硬阻断）：
1. Dockerfile 的 HTTP_PROXY/HTTPS_PROXY 默认指向内网代理 → 他人构建必失败
2. zd-host.sh 是升级脚本（要求已存在 host 模式 navi 容器）→ 新机器第一句过不去
3. docker-compose.yml 是桥接+端口映射，与'统一入口 host 模式'口径冲突
4. 证书文件名约定未文档化（实际来自 gateway.yml 的 certFile/keyFile）
5. 环境变量表不完整、缺 sshpass 依赖说明
本次：
- Dockerfile：代理默认置空，需要时 --build-arg 传入
- deploy/install-host.sh（新）：干净机器首次安装，6 步并在任一步失败即停，
含端口独占检查、证书检查、初始 gateway.yml 生成、apply、四项自检，
令牌可自动生成并只打印一次；已存在 navi 容器时拒绝执行（引导去 zd-host.sh）
- docker-compose.yml：标注为试用形态，指向 install-host.sh
- README：新增「从零部署（干净机器）」——两条路径分工表、前置条件表、
完整环境变量表、证书与初始网关配置说明、装完自检命令；自定义文件表登记新脚本
另修：脚本自检原用 /.navi-ping（该路径已按用户要求删除），改用 /conf.yml。
|
2026-09-12 09:37:45 +08:00 |
|
|
|
cb86557466
|
test(gateway): root 去重断言改为按 server 段计数
上一版断言用全局计数，而默认段与门户段各有一个 root（合法），因此必然失败；
真正要防的是同一段内重复。改为取门户段后再计数。
|
2026-09-12 09:20:35 +08:00 |
|
|
|
b4241741d6
|
fix(gateway): 门户段重复 root 导致 nginx -t 失败
v52 部署被 apply 的校验拦下（"root directive is duplicate"）：writeErrorPages 已写过
root /app/portal;，我又在 portal 分支写了一次。移除重复行，并加单测断言
该指令在生成结果里恰好出现一次。回滚机制按预期工作，服务未中断。
|
2026-09-12 09:20:18 +08:00 |
|
|
|
52164b6abe
|
fix(gateway): 门户首页走 admin-server 渲染（上次改动未落盘）
上一轮声称改过 kind=portal 的生成逻辑，但 git log 显示 gateway.go 从未提交该改动
（我的修改没有真正落盘），导致：线上仍用内置模板，而新镜像的模板带 HTML 占位符
→ 门户页占位符裸露、标题为空、文案不可配置。
本次：portal 分支改为 location = / 反代到 :3005/portal-page（静态资源仍 root
/app/portal），并新增单测断言该引用存在——今后若再被改掉，测试会失败。
|
2026-09-12 09:17:34 +08:00 |
|
|
|
13ab2336c6
|
fix(deploy): host 部署后自动重新生成一次网关配置
事故：门户首页改为由 admin-server 渲染（/portal-page）后，镜像里的门户模板带
HTML 占位符，而线上 gateway.conf 仍是上一版生成的（未引用渲染器），导致
门户页占位符裸露、标题为空。
在 zd-host.sh 的入口自检之后加入 apply 步骤（用同一份 env 里的 admin token），
失败即中止并回滚，避免镜像已更新但配置没跟上这类静默不一致。
|
2026-09-12 09:16:38 +08:00 |
|
|
|
472d8d1cd0
|
feat(pages): 认证页与门户页文案可配置，不再写死
需求：登录页与门户页的内容应可自定义。
实现（配置存数据卷、后台可改、留空回落内置默认，不配置行为不变）：
- pages.go：pageStr 读取 pageInfo；renderPortalPage 优先数据卷
<data>/portal/index.html 整页覆盖，否则用内置模板替换占位符；
authPageInfo 提供登录页字段
- auth.go：登录页标题/副标题/徽标/页脚改为模板数据（含备案号）
- gateway.go：kind=portal 的首页改由 admin-server /portal-page 渲染
（静态资源仍由 nginx 提供），使文案可配置
- portal/index.html：加入 <!--PAGE_TITLE--> / <!--HERO_TITLE--> /
<!--HERO_SUBTITLE--> / <!--FOOTER--> 占位符
- 后台「站点信息」新增六项文案输入（含回填与保存），并提示整页覆盖方式
- README 新增「认证页与门户页文案（可配置，不写死）」含字段表与自检命令
测试：默认回落、配置取值去空白、认证页字段读取、数据卷覆盖优先、空白覆盖忽略。
|
2026-09-12 09:12:13 +08:00 |
|
|
|
352aa570ec
|
chore: 验收脚本入库（矩阵/工作空间/滚动）+ 修正脱敏自检命令
- deploy/verify-matrix.js：6 尺寸 × 3 视图 × 深浅色矩阵，断言纵向滚动（仅
minimal/workspace）、文字亮度阈值、深色是否生效、零运行时异常
- deploy/verify-workspace.js：触发 workspace blocked 态，读弹窗卡片 computed style
- deploy/verify-scroll.js：多视口滚动复现（含 900x520 这类矮窗口）
三者只从环境变量 PORTAL_COOKIE 取会话，无任何硬编码凭据
- README 自检命令改为排除占位符（<...>、${VAR:-}、change-me），避免误报
- 自定义文件表登记上述脚本
|
2026-09-12 08:55:04 +08:00 |
|
|
|
323d494615
|
docs: 补齐一体化模式教程、自定义文件清单与脱敏清单
- 新增「一体化模式」章节：单容器即统一入口（TLS + 统一登录 + 导航 + 搜索 + 历史/管理）
· 端口与挂载（内部 18080 / 对外 3080、8443 / 跳转 3081；data 卷 + 证书只读卷）
· host 模式部署命令与失败自动回滚；说明 zd.sh 双端口轮换在合并后失效的原因
· 切换四步、服务转发字段（含逐条统一认证与导航绑定）、现有 nginx 配置导入
· 统一登录账号（数据卷存加盐哈希，优先级与生效方式）
· 深浅色/壁纸/状态点关闭的原因（含 background 简写清掉壁纸的坑）
· 回滚路径（容器、配置备份、数据卷）
- 「部署需要的全部自定义文件」表补充：deploy/zd-host.sh、portal/、auth.go、
gateway*.go、portal_auth.go
- 新增「绝不提交的内容（脱敏清单）」：conf.yml/备份、各类 token 与口令、portal-auth.json、
证书、运行时 env 与 nginx 备份；并给出两条发布前自检命令
- 零停机部署与 portal-nginx 两节加指引，避免照旧流程操作
|
2026-09-12 08:54:33 +08:00 |
|
|
|
f08e0bf844
|
fix(workspace): 弹窗卡片在深色下仍是白卡（补齐）
实测（打开被拒绝内嵌的应用时弹出提示）：
.navi-ws-modal 遮罩已是深色，但 .navi-ws-modal-card 仍为 rgba(255,255,255,.96)，
深色下是刺眼白块且与浅色文字冲突；按钮同样是亮色。
补齐卡片/标题/正文/按钮的深色样式。内嵌区上一条已改为透明（去黑方块）。
|
2026-09-12 08:39:43 +08:00 |
|
|
|
b794aed18e
|
fix(workspace): 去掉内嵌应用区的黑方块（改透明）
用户反馈工作空间深色下有黑色方块。实测：亮色时代该区域是 #fff，我在 v44
把它改成 #0f172a，于是打开应用时那块区域变成一整块不透明黑。
修法：内嵌区与 iframe 一律透明（露出壁纸/玻璃底），应用自身背景照常显示，
空态也不再出现突兀方块。深/浅两种模式行为一致。
|
2026-09-12 08:37:02 +08:00 |
|
|
|
9798b68d07
|
feat(status): 按用户要求彻底关闭可达性状态显示
用户决定不显示服务状态，避免不准确的信号误导。因此：
- 移除导航同步里写入的 statusCheck / statusCheckUrl
- 移除网关为每条路由生成的 /.navi-ping（不再需要，且不应保留一个
免认证旁路路径）
- 删除对应单测
生产 conf.yml 的 statusCheck 在同一次部署中关闭（appConfig 置 false、
条目级该行删除），并重新 apply 生成网关配置以清掉 /.navi-ping。
|
2026-09-12 08:32:03 +08:00 |
|
|
|
da7a56e7ec
|
fix(status): 修掉 Dashy 可达性检查"全黄"——改用免认证探测路径
用户反馈可达性全黄。实测：appConfig.statusCheck 已开启，但等 6 秒仍无状态
节点渲染；上游直连全部 200。机制：Dashy 用 no-cors 探测条目 URL，而受保护域名
会 302 跳到另一个域（登录页），no-cors 下跨域重定向直接报错 → 检查永远停在
"进行中" → 全黄。
修法：
- gateway 为每条路由生成 location = /.navi-ping：auth_request off + 反代到
真实上游（上游挂了返回 5xx → 红；正常 2xx → 绿），portal 类型直接 204
- 导航同步时设置 NavItem.StatusCheck = true 与 statusCheckUrl 指向该路径
- 注意：statusCheck 是 NavItem 的结构体字段，不能塞进 inline Extra（yaml 会
panic: conflicts with struct field）——已改为设置字段本身
测试：新增断言——探测路径存在、免认证、反代到真实上游、portal 返回 204。
|
2026-09-12 08:23:33 +08:00 |
|
|
|
2d3b1e31de
|
fix(layout): 矮视口下备案号移出文档流，彻底修掉 minimal 纵向滚动
实测：仅压缩内边距后 .navi-footer-host 仍有 37px 高且在 flow 中，
900x520 下 minimal 的 scrollH=536 > viewH=520（溢出 16px）。
改为 position:fixed 后不再撑高页面；搜索栏与按钮组已在 bottom:60px，不会相撞。
workspace 视图原本就是这样处理。
同时记录另一处误判：矩阵里"900x520 失去深色"是我等待不足（2s）抢在
navi.js 应用主题前测量所致；复测 mq=true/navi-dark 均已生效，深色无问题。
|
2026-09-12 08:12:09 +08:00 |
|
|
|
67038ce4de
|
fix(layout): 矮视口下备案号不再撑高页面（修 minimal 纵向滚动）
实测复现：900x520 时 .navi-footer-host 由 39px 换行涨到 69px，因处于文档流
（margin-top:auto）把页面顶高 47px，minimal 出现纵向滚动；1280x720 等常见尺寸
复现不出来，所以此前漏检。
只对 max-height:560px 收紧：缩小内边距/字号 + 禁止换行，并同步上移搜索栏
与按钮组，避免与备案号相撞。高窗口与移动端不受影响。
|
2026-09-12 07:55:22 +08:00 |
|
|
|
c8f6ac68fe
|
fix(theme): workspace/minimal 深色补齐（侧栏白色药丸、内嵌应用白框）
实测（computed style）：
- nav.side-bar 已是深色，但 .side-bar-item 仍为 rgba(255,255,255,.7) 白色药丸
- .work-space .web-content 为 rgb(255,255,255) 纯白，深色下形成刺眼白框
- .navi-ws-bar-btn / 工具条 / 提示框一并补齐深色
minimal 的纵向滚动在 1280x720 下复现不出来（scrollable=false），
需要用更矮视口复现后再修，避免凭猜测改动布局。
|
2026-09-12 07:53:08 +08:00 |
|
|
|
064f986a7f
|
fix(theme): 深色遮罩交给服务端，避免双重压暗
实测发现深色下 body 的 background-image 仍是亮色的 70% 白遮罩（壁纸被洗白）。
遮罩由服务端 applyWallpaperBlock 写进 conf.yml，因此在那里补一条深色规则
（同一张壁纸 + rgba(6,12,24,dim+0.15) 遮罩），并移除 navi.css 里那层
body::before 遮罩，避免壁纸被双重压暗。加单测断言深浅两条规则共存、
且移除壁纸时一并清除。
|
2026-09-12 07:49:34 +08:00 |
|
|
|
1257164c3f
|
fix(theme): 备案号深色药丸 + 确认不再用 background 简写
浏览器规则枚举确认元凶：navi.css 的 html.navi-dark body 用 background 简写
（特异性 0,2,1 > 壁纸规则 0,1,1），简写把 background-image 重置为 initial，
于是壁纸消失。本地已改为仅 background-color + body::before 深色遮罩。
同时按实测补上备案号药丸的深色样式（此前实测仍是 rgba(255,255,255,.55)），
并把内部元素强制透明，避免深底上贴一块白。
实测数据：备案号位于文档最底部（y=1079..1125 / 文档高 1125），与悬浮件无重叠。
|
2026-09-12 07:46:09 +08:00 |
|
|
|
e064ef5296
|
fix(theme): 深色不再抹掉壁纸，改为深色遮罩压暗
用户反馈深色下背景图片消失。原因：我在深色里用了 background 简写并带
!important（特异性 0,2,1 > 壁纸规则的 0,1,1），把壁纸的 background-image
清成了 none。
改为：只覆盖 background-color，另加 body::before 深色遮罩（与亮色模式
白色遮罩同思路，z-index:-1 是本站既有做法），壁纸依旧可见、只是变暗。
同时修正上一轮验证方法的缺陷：那几次"看到旧样式"是浏览器缓存造成的假象。
|
2026-09-12 07:40:56 +08:00 |
|
|
|
a78c5180ca
|
fix(deploy): host 模式远端显式接收 VER
首次 host 部署在停旧容器后因远端 VER 未定义触发 unbound variable 而失败
（当时旧容器仅被改名未恢复，已手工恢复）。此处只补参数传递，不改动
heredoc 结构与回滚顺序。
|
2026-09-12 07:36:20 +08:00 |
|
|
|
817a5991b3
|
fix(theme): 基于真实浏览器渲染修复深色文字与右侧方块
此前只检查 CSS 规则存在，没有检查真实页面 computed style，导致标题、分组标题、
卡片正文仍被前面的亮色 !important 规则覆盖；右侧 dock/view-switch 布局容器也被
错误涂上背景，形成灰色方块。
这次通过共享 Chromium 实际登录并强制深色模式，逐项读取 computed style：
- 顶部标题 #f1f5f9
- 分组标题 #dce6f5
- 卡片主文字 #f1f5f9、说明 #a9b8cd
- 分组/卡片使用协调的深色玻璃层级
- dock 与 view-switch 布局容器完全透明，仅两个圆形按钮着色
- 备案号为完整深色胶囊，子元素透明
- 工作空间/极简视图同步补齐深色侧栏、工具条和弹窗
自动验证同时断言：文字亮度、深色面板、透明容器、圆形按钮、零运行时异常。
新增 deploy/zd-host.sh，供单容器正式接管入口后的 host 网络部署使用；失败自动回滚。
|
2026-09-12 07:30:00 +08:00 |
|
|
|
44e2792f0e
|
fix(theme): 深色下主页底色与右下悬浮件仍不生效
现象：主页大面积没变深；右下角仍有一块灰色方块。
根因：
1. conf.yml 的玻璃主题用 html[data-theme] body 设了亮色背景，特异度与
html.navi-dark body 相同(0,1,1)，而 customCss 由 Dashy 运行时注入、排在
navi.css 之后 —— 平局时后者胜出，所以页面底色没被改掉。
2. 右下那块是我们自己的悬浮件，但此前只逐个类名列举，漏掉的类名就保持原样。
改法：
- navi.js 把 navi-dark 同时打到 <html> 与 <body>（并在 DOMContentLoaded 再应用一次）
- navi.css 用 html.navi-dark body.navi-dark 提高特异度到 (0,2,1)，压过 customCss，
与注入顺序无关
- 兜住 Dashy 外层容器（#dashy/.home/.workspace/.minimal-home）与原生页脚
- 用 [class^="navi-"]/[class*=" navi-"] 整体兜住我们注入的悬浮件，避免再漏类名
|
2026-09-11 23:38:56 +08:00 |
|
|
|
b1e4367937
|
fix(theme): 深色改为整套主题变量覆盖，不再改写 data-theme
用户反馈"深色区域有的方形、有的根本没变深"。根因有两层，都是我的做法错了：
1. navi.js 会把 <html data-theme> 改成 "dark"。Dashy 的配色变量是按主题名
作用域输出的（本站主题 jianf-glass），改掉它 → 整套主题变量失配 →
有的区域完全没变深。
2. navi.css 之前只覆盖"页面底色 + 我们自己的悬浮件"，Dashy 自己的卡片/侧栏/
头部仍走原主题 → 与深底色拼在一起，就成了直角圆角混杂。
改法：
- navi.js 只切 <html class="navi-dark">（并设 color-scheme），绝不碰 data-theme
- navi.css 用 html.navi-dark 一次性覆盖 jianf-glass 的全部配色变量（47 个：
背景/卡片分组/条目文字/侧栏/头部导航/搜索框/设置面板/弹层/滚动条/语义色），
Dashy 自身界面随之整体一致变深；形状由元素自身样式决定，不再混杂
- 选择器 html.navi-dark 特异度(0,1,1) 高于 [data-theme=…](0,1,0)，与注入顺序无关
需要目视确认配色层次（变量值只能看着调）。
|
2026-09-11 23:31:27 +08:00 |
|
|
|
1c20cab519
|
fix(admin): 后台设置页支持自动深浅色
反馈"设置页也没有"：/admin/ 只有一套亮色变量（我写它时没做主题），
不跟随系统也不跟随导航页/登录页的手动选择。
- head 内联引导脚本：localStorage['navi-theme'] 优先，其次 prefers-color-scheme
- 深色下整体替换 CSS 变量，并补掉少数写死的白色
（输入框/按钮/列表项/图片底/阴影），加 color-scheme 让原生控件与滚动条跟随
- 与导航页、登录页共用同一个 storage 键，三处观感一致
|
2026-09-11 23:23:15 +08:00 |
|
|
|
a8ce6ad759
|
feat(theme): 导航页恢复自动深浅色（跟随系统），保留隐藏原生设置入口
用户反馈：现在没有自动深/浅色。实测原因有两层：
1. Dashy 原生的日/夜切换按钮在设置面板里，而该面板按要求被隐藏；
2. navi.css 没有任何 prefers-color-scheme 分支，且多处写死亮色。
本提交按"我们自己接管"实现（不去赌 Dashy 压缩后的主题存储键）：
- navi.js：默认跟 prefers-color-scheme；手动切换过以 localStorage.navi-theme 为准；
系统偏好变化实时跟随；给 <html> 设 data-theme 与 .navi-dark，并设 color-scheme。
Dashy 挂载后可能覆写 data-theme，用短暂定时对齐 + 属性观察器收口
（仅在"与期望不一致"时回写，避免自激循环）。
- navi.css：深色下覆盖页面底色与文字，以及我们自己注入的悬浮控件
（搜索条/收边控件/页脚/工作空间工具条与弹窗/迷你视图标签条）。
选择器带 body 以压过主题注入的 customCss。
需要人工目视确认观感（深色下的玻璃层次只能靠眼睛调）。
|
2026-09-11 23:18:54 +08:00 |
|
