tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
138 Commits 1 Branch 0 Tags
812b70cb4ccfd51c8e811e938993be09ea363973
Commit Graph
62 Commits
Author SHA1 Message Date
tamakyi 812b70cb4c fix(user/questions): 筛选标签改为「已读 是/否」，手机端条目标签行不再折行 
- 筛选栏第 5 列标签「阅读状态」四字，在手机约 53px 的窄列里必然折成两行，
  改为「已读」，选项改为 全部/是/否（option value 仍是 read/unread，后端不变）。
  词条 qlist.readStatus 由 qlist.readFilter + qlist.filterYes/filterNo 取代，四语言同步。
- 条目行「时间 + 状态标签 + 标记/置顶」在手机上放不下：实测 360 宽可用 306px，
  完整时间单条就占 127px，2 标签 + 2 按钮需 343px。手机端时间改为「月-日 时:分」
  （tb-short/tb-text 复用状态标签的 640px 断点，桌面端仍显示完整年月日时分秒），
  同时把 .qlist-pill 的基础内边距 40/8 收到 34/6（桌面 @media 仍覆盖回 62/10）。
  结果：2 标签 + 2 按钮在 360 宽即单行；三标签（私密+待答+未读）在 ≤375 仍会折行。
 2026-10-23 21:02:37 +08:00
tamakyi 86ea96e5ca feat(autoban): 封禁响应图改为 ban_image_path 配置，默认仍是纯文字 
上一版把 403 图 //go:embed 进了二进制。实际部署里图会集中放在 R2 统一管理、
由运维分发到各机器，进仓库反而成了负担：换一张图就要重新编译。

改为配置驱动：
- 新增 [security] ban_image_path（相对路径以进程工作目录为基准）；
- 留空 / 文件读不到 / 是目录 / 不是图片 / 超过 2 MB → 一律回退为纯文字
  "403 Forbidden"，即改造前的老行为。封禁响应是最后一道兜底，不能因为
  一张图缺失就变成 500，更不能把站点拦在启动阶段（失败只 Warn）；
- 启动时读一次装进 atomic.Pointer，热路径零磁盘 IO；换图 = 换文件 + 重启。

安全细节：按内容嗅探（http.DetectContentType）而不是扩展名，必须是 image/*。
把 ban_image_path 配成 app.ini / .env 会被拒绝并告警 —— 否则等于把配置文件
原样吐给每一个被封的攻击者。这条有专门的用例与变异验证。

顺带删掉 internal/route/assets（webp + embed），已无引用。

测试：
- TestWriteBannedTextFallback：未配图 → 403 + text/plain + 13 字节明文；
- TestWriteBannedServesConfiguredImage：配了 1×1 PNG → image/png（按内容嗅探）、
  Content-Length 与文件一致、body 与文件逐字节相同；
- TestLoadBanImageRejectsBadInput：不存在 / 是目录 / 非图片 / 空文件四种配置错误
  都不得装载，且**不得把文件内容当响应体吐出去**；
- TestLoadBanImageTooLarge：超 2 MB 拒绝；
- TestWriteBannedHead：两条分支的 HEAD 都只回头不给 body。
变异验证：去掉 image/* 校验 → 用例报「把文件内容当响应体吐了出去：
"[server]\nsalt = secret"」；强制走纯文字分支 → 配图用例按预期变红。

实测：真 webp 嗅探为 image/webp；app.sample.ini 嗅探为 text/plain 被拒。
 2026-10-23 15:25:07 +08:00
tamakyi 0318ba81b4 feat(autoban): 封禁响应体改成一张 403 图片 
被封禁来源访问任何路径时，原来只回 13 字节的 "403 Forbidden"：既没有信息量，
人肉访问（尤其是共享出口被连累的误封）时看着像站点挂了；扫描/爆破脚本也常靠
读这行明文确认「自己已被拦」。

改为返回一张 256×256 的 webp（约 8.6 KB，画面写着 403 Forbidden），状态码不变：
- 图片用 //go:embed 编进二进制，不依赖外部 URL、不占公开路径；
- 显式给 Content-Length（8 KB 超过 Go 的 2 KB 写缓冲，不设会退回 chunked）；
- Cache-Control: no-store —— 中间层缓存 403 没有意义，还会让解封后的响应继续命中；
- HEAD 只回头不写 body；
- 放在 internal/route/assets/ 而不是 static/：static 下的东西有可公开访问的 URL，
  等于多一个指纹入口。

注意链接：给的 R2 预签名地址 X-Amz-Expires=604800（7 天），热链到期就会挂，
所以是把字节取回来打包，而不是重定向或代理。

测试：
- TestWriteBanned：状态码 403、image/webp、Content-Length 与内嵌字节数一致、
  body 前 12 字节是 RIFF/WEBP（防止被换成 HTML 或明文这类回归）；
- TestWriteBannedHead：HEAD 无 body 但有 Content-Length；
- 原 TestHoneypotBansEvenWhenAutoBanDisabled 里断言 "403 Forbidden" 明文的用例
  改为断言 image/webp 与体积。
变异验证：把 writeBanned 改回写明文 + text/plain，两条用例均按预期变红。
 2026-10-23 15:04:13 +08:00
tamakyi 307bd94ed1 feat(honeypot): /xmlrpc.php 走真实 XML-RPC，动态 token 不再恒定 
线上验收发现两个「能被指纹识别」的破绽，都不影响原有功能但削弱伪装：

一、/xmlrpc.php 回的是 HTML 登录页（P1）
我们自己发的响应头里就有 X-Pingback: /xmlrpc.php —— 扫描器顺着跟过来，
一看是 HTML 就知道整站是假的（真实 WordPress 在这里回 text/xml）。
更可惜的是 system.multicall 这条通道被浪费：一次请求能带上千组用户名/密码、
且绕开登录页限速插件，是 WP 爆破里产出最高的入口。

新增 xmlrpc.go：
- 非 POST → 405 + fault「XML-RPC services are disabled on this site.」（与真实 WP 一致）
- POST methodCall → 200 + fault「Incorrect username or password.」（不区分用户是否存在）
- POST system.listMethods → 200 + 方法列表（枚举类工具靠它确认对面是真 WP）
- 凭据提取刻意不上 encoding/xml（蜜罐被高频命中）：抓所有 <string>、剔除
  methodName 与站点 URL 后两两配对。wp.getUsersBlogs 的 blog_id 若是短数字会让
  配对错位一位，故「奇数长度 + 首项短数字」时丢首项；另外原始串全量写进
  fields（xmlrpc.0/1/…），配对失败也不丢原文。
  multicall 的第一组进标准字段，其余进 cred2/cred3… —— 一个用户名配一长串
  密码是常见字典形态，只留第一组等于丢掉整份字典。
- 封禁与表单提交同规则：带凭据走 RecordHoneypot（立即封），否则走常规阈值。

二、进入页面的隐藏值每次请求都一样（P2）
两次请求拿到同一个 pma token / csrf_token / X-Jenkins-Session，任何脚本都能
判定对面是伪造的。改为按请求生成 32 位 hex（math/rand/v2 —— 这些是假 token，
不需要不可预测，只需要每次不同；crypto/rand 在 Windows 要走系统调用，贵一个量级），
页头、hidden 与 Set-Cookie 共用同一套。

顺带：
- X-Pingback 改绝对地址（$base/xmlrpc.php）。真实 WP 给绝对 URL，相对路径本身
  就是破绽；没配 external_url 时干脆不发这个头。
- Cache-Control 从 no-store 改 no-cache, must-revalidate, max-age=0
  （no-store 更像安全设备/代理加的，不像登录页）。
- Grafana / GitLab 补上真实产品会种的会话 cookie（grafana_sess、_gitlab_session）。
- Match 增加 .php 变体兜底：清单里是 /phpinfo，扫描器打 /phpinfo.php，
  原来漏掉 → 302 回首页，等于明确告诉对方「这个文件不存在」。

测试：xmlrpc_test（IsXMLRPCPath / getUsersBlogs / multicall / 数字 blog_id /
非 XML-RPC body / fault 与 listMethods 输出）、family_test（动态 token 两次不同且
是合法 hex、X-Jenkins-Session 与 correlation_id 动态、Pingback 绝对地址与缺省不发、
所有家族渲染后不残留 $ 占位符）、route 层（POST multicall 捕获凭据 + 立即封 +
回 text/xml；GET 回 405 fault 而非登录页）、honeypot（.php 变体命中且不牵连业务路径）。
四处变异验证均按预期变红：固定 token、xmlrpc 分支失效、Pingback 退化成相对路径、
.php 兜底失效。

性能：RenderFamily 3.7µs→4.18µs、2→3 allocs（多的一次是 hex 编码），
AssetFor 仍 0 分配。
 2026-10-23 12:58:48 +08:00
tamakyi 811578dcf1 feat(honeypot): 按扫描目标伪装成 9 类后台，静态资源不落库 
原来所有诱饵路径都回同一个 WordPress 登录页。爆破工具的标准流程是
「先按路径判断这是什么后台，再拿它认识的字段名填表」——在 /phpmyadmin/index.php
上回 WP 表单，等于告诉对方「这里没有 PMA」，对方直接换目标，既拿不到凭据
也没有取证价值。

新增 family.go（皮肤表）+ asset.go（静态资源占位），page.go 改为按家族渲染：

  wordpress   /wp-login.php /wp-admin /wp-json    log/pwd、wordpress_test_cookie
  phpmyadmin  /phpmyadmin /pma /adminer.php       pma_username/pma_password、hidden token
  tomcat      /manager/html /host-manager         401 + WWW-Authenticate: Basic（无表单）
  jenkins     /jenkins /jnlpJars                  j_username/j_password、X-Jenkins
  grafana     /grafana                            user/password、深色主题
  gitlab      /users/sign_in                      user[login]/user[password]
  luci        /cgi-bin/luci /luci                 luci_username/luci_password
  joomla      /administrator                      username/passwd、hidden option=com_login
  generic     /admin /console /zabbix /jira…      username/password

Tomcat 刻意不给 HTML 表单：真实 Manager 未认证就是 401 + Basic 弹框，给表单
反而更假；Authorization: Basic 本就在 ExtractCredentials 覆盖范围内，捕获能力不减。

凭据字段：
- credentialKeys 扩 pma_* / j_* / luci_* / user[login] / user[password]；
- token 只用于判 HadFields，**移出 isPasswordKey** —— PMA/GitLab 的登录表单带
  hidden CSRF token，而 Fields 是 map、遍历无序，原来的实现会让 token 随机
  顶掉真密码，记录下来的「密码」时对时错。

资源占用（这是本次主要约束）：
- 渲染一页 3.7µs / 2 次分配 / 5.2KB（改前 12µs / 22 次 / 19.5KB）：
  不用 html/template（每次 ParseFS 是毫秒级 IO+编译），改单次 strings.Builder
  并避免 "a"+b+"c" 反复分配，Replacer 提到包级；
- 静态资源请求 55ns / 0 分配：CSS/JS 回常量片段、图片回真 1×1 PNG，
  **不解析 IP、不判封禁、不写库**——真实后台页一次加载 5–10 个资源请求，
  否则等于把页面浏览放大成十几条 INSERT。插件目录下的 .php 回 404（webshell 探测）。

honeypot paths 增加家族汇总，便于确认实际生效的分布。
新增 dev/preview-honeypot：把 9 个家族渲染到 outputs/honeypot-preview/index.html
再配 headless 截图核对外观——本轮两个「源码看不出、截图一眼假」的问题
（Tomcat 忘配 css 导致按钮白字无底色、WP 登录页底部挂着 404 文案）都是它发现的。

测试：TestFamilyOf / TestEveryFamilyRendersItsOwnFields / TestTomcatUses401Basic /
TestAssetFor / TestRenderIsCheap（4KB 上限）/ BenchmarkRenderFamily /
BenchmarkAssetFor，route 层 TestHoneypotServesFamilySpecificPage /
TestHoneypotCapturesFamilyFields / TestHoneypotAssetRequestsAreNotRecorded。
变异验证：资源短路失效 → 3 个资源全变 text/html 且落库；FamilyOf 恒返回
Generic → 页面缺特征字段。两项均按预期变红。
 2026-10-23 12:38:35 +08:00
tamakyi 818fa74160 fix(honeypot): 取证记精确地址、封禁用 /64 键，并补建封与拦截日志 
线上实测：IPv6 访问蜜罐后收到「你的 IP 已被封禁」，邮件里却是
`2408:…::/64` —— 既不像自己的地址，也说不清封了多大范围；同时用户自己
仍能正常访问，看日志也无从判断到底有没有封。

根因是「取证地址」与「封禁键」混用同一个变量（都取 LimitKey 的折叠值）：
- 取证丢掉精确 IPv6 后 64 位，事后无法定位到具体主机、没法和其他日志对账；
- 邮件只给聚合键，运维第一反应是「不是我」，排查方向直接被带偏。

改动：
- Serve 拆 clientIP（ResolveClientIP，精确）与 banKey（LimitKey，/64）：
  DB / 凭据文件 / 告警邮件用前者，封禁 / 探测采样 / 告警去重用后者；
- autoban.Options 新增 OnBan 回调（保持纯标准库、不引入 logrus），
  route.newBanner 注入后每次建封打 WARN：ban_key / reason / duration / expires_at；
  中间件 403 分支加 Debug 日志（被封者会持续请求，Info 会被刷屏）；
- 告警邮件新增「封禁范围」行，仅 ip != ban_key 时渲染（IPv4 不重复显示），
  顺带把过时的「已入库」改为「写入取证文件」——凭据早就外置了；
- honeypot stats 的来源排行改按 LimitKey 合并，否则 IPv6 轮换地址会把
  排行碎成几十条各 1 次的记录；合并口径与封禁完全一致。

测试（每项都做了变异验证：改坏→确认变红→恢复）：
- TestHoneypotRecordsExactIPv6ButBansByPrefix：精确地址进 DB 与凭据文件、
  /64 才是封禁键、同 /64 换地址仍 403；
- TestOnBanCallback：建封回调带键/时长/原因，封禁期内重复命中不重复回调；
- TestHoneypotAlertTemplateRenders：IPv6 渲染封禁范围、IPv4 不重复；
- TestMergeSourcesByKey：同 /64 合并、IPv4 原样、limit 与空输入。
 2026-10-23 10:53:03 +08:00
tamakyi b939d26ff0 fix templates v2 2026-10-22 17:49:25 +08:00
tamakyi bd02eb7ed2 fix templates v1 2026-10-22 17:04:10 +08:00
tamakyi 8941744621 new-sakura：顶栏改半透明磨砂，并立规矩禁止全透明 
线上（box.shiroko.one/_/tamakyi）两个现象来自同一处：`--tb-navbar` 是实色，
顶栏那条带（y=20..80）把从右上角长出来的花枝齐刷刷切掉一段。

第一版顺手改成 transparent —— 花枝完整了，但顶栏"消失"：导航失去依托，
文字直接压在花纹上。用户当场否掉，要求半透明。

- 顶栏：`rgba(253,246,248,0.72)` / 深色 `rgba(34,26,30,0.72)`，配
  `.uk-navbar-container{backdrop-filter:blur(12px)}`（令牌只能是颜色，模糊写在规则里）。
  0.72 有依据：导航文字 #6d555d 纯底 6.34:1，最坏情况（深花瓣在顶栏后面）压平后 5.08:1。
- 花枝 top -16px → 26px：顶栏半透明后，700~760px 宽度下枝头正好压在「登录」上（截图确认）。
- 手机底栏 #tb-mobile-utils 在 base.css 写死 rgba(255,255,255,.92)，粉底上是一条白杠，
  主题里改成同色系 0.92。
- 新增 TestNavbarNotFullyTransparent：拦 `transparent` / `rgba(...,0)` / `#rrggbb00`，
  并说明"这不是审美偏好，是踩过之后立的规矩"。变异验证过（改回 transparent 立即 FAIL）。
  约定同时写进 static/css/themes/_scaffold.css 的令牌说明。
- StaticVersion 20261022b → 20261022c：css 改了不提版本号，浏览器拿着旧样式，
  现象就是"改了但线上没变"。
 2026-10-22 16:05:37 +08:00
tamakyi 2981731d4f announcement v3 2026-10-22 15:28:04 +08:00
tamakyi e1e840f895 announcement v1 2026-10-22 15:08:24 +08:00
tamakyi c9f22cb81b 修窄屏装饰层压不住作用域块（手机上一直显示桌面版樱花） 
@media 不提升特异性：作用域块 html[data-theme-style][data-page-scope="box"] 是 (0,2,1)，
媒体查询里写的 html[data-theme-style] 只有 (0,1,1)，于是「窄屏装饰层全置 none」这行
从来没生效 —— 手机上照样铺开桌面的花枝与花朵。深色作用域块是 (0,3,1)，更压不住。

- 媒体查询里补三条同特异性的通配规则（作用域 0,2,1 / 深色基础 0,2,1 / 深色+作用域 0,3,1），
  媒体块在文件更后，同特异性即胜出。
- 新增 TestNarrowMediaOverridesScopedDeco：外层每处非 none 的 --tb-deco，都要求窄屏里有
  同属性名、属性数不少于它的声明。变异验证过（删掉深层那条立即 FAIL）。
  它同时报出 shiroko 的 900px 块只覆盖浅色 —— 但深色块本就是 none，不算缺陷，故跳过。
- 窄屏改由加强版底纹承担樱花（透明度 ×1.9、格子 180px）：桌面那套 0.18~0.34 的透明度
  在 390px 上实测接近纯粉。顶栏与卡片之间那条 35px 带子试过放小花，question/admin 页卡片
  从 y=110 起会切掉一半，最终不放装饰层。
 2026-10-22 11:18:29 +08:00
tamakyi 48a1938fb2 新增 new-sakura 主题：纯 CSS 樱花，每个页面位置不同 
樱花不依赖任何图片素材：整朵花、带缺口的花瓣、带枝的花朵树都是内联 SVG 的
data URI，写在主题 CSS 里。好处是零请求、任意缩放不糊、换花色只改一个色值；
代价是 CSS 约 50KB（gzip 约 12KB），走 StaticVersion 缓存。

- 六个页面作用域各一套 --tb-deco 位置（global / box / question / admin /
  profile / vote），10 槽三组等长；位置一律「关键字 + 偏移」两值写法。
- 窄屏（≤640px）装饰层全关、底纹缩到 200px：卡片占满宽度后枝条会糊在字上。
- 深色换亮一档的粉、关掉底纹（浅粉压在深底上会变噪点）、背景用渐变避免死黑。
- 亮色 primary 从候选 #c14a72（4.39:1）压深到 #b8436a（4.87:1），
  muted 5.27:1，都踩住 AA；深色对应 8.17:1 / 5.82:1。
- 生成脚本 dev/theme-tools/gen_new_sakura.py（花形、位置表、配色都在里面），
  CSS 是产物，不手改。
- 四份词典加 theme.name.new-sakura；conf/app.sample.ini 的 available 登记。

为什么不用生成器：生成器的装饰层只认图片素材，没有内联 SVG 图层，
见 docs/theme-new-sakura.md「为什么不用主题生成器出图」。
 2026-10-22 10:45:39 +08:00
tamakyi 34a262091b 修 shiroko 单车/步枪素材「白色没抠」：白上白只能全白转透明 
根因不是抠图参数：素材是白底+白车架，车架涂装与背景白是同一个值（都是 #f9f9f9），
颜色上无法分离。四角 floodfill 只吃掉外圈，轮圈内、车架三角、车筐、枪与车架之间的白整块留着，
量化就是不透明像素里近白(>240) 占 50%。

- 处置：min(r,g,b)≥238 软过渡 + 饱和度>14 保留彩色 → 白全透明。近白降到 0.0%，
  不透明率 19.4%，29KB；轮辐/车架/车筐成为描边，粉轮圈、蓝枪托、接触阴影保留
- 试过「按近白厚度区分白洞与白涂装」（腐蚀测厚度）→ 失败：轮辐间扇形白楔 9~13px 与车架管
  5~10px 重叠，阈值怎么调都会留白楔，比原图更难看
- 画布保持 397×259 不裁：deco-size 是 auto 259px，宽度按比例算，裁了锚点会漂
- css 图片 ?v= → 20261021a；StaticVersion 20261021c → 20261021d（css 内容变了必须换缓存键）
- docs：assets-spec 补「白上白」取舍与验收项「不透明像素近白占比≈0」，theme-shiroko 素材表同步
 2026-10-21 19:18:50 +08:00
tamakyi 1f29d3eb2e 修设置页主题色块被模板过滤器替换成 ZgotmplZ 
html/template 对 style 属性做 CSS 过滤，linear-gradient(...) 未标记安全会被整体替换成
ZgotmplZ —— 线上设置页四个主题色块一直是灰底（既有问题，不是这次配色改动引入）。

- FuncMap 新增 safeCSS（string → template.CSS）；值只来自 internal/theme.swatchOf，
  由两个已校验的色值拼成，不接受用户输入，所以这里放开是安全的
- user/profile.html 的色块改 {{ safeCSS .Swatch }}
- 新增 TestThemeSwatchRenders：渲染 user/profile，断言不含 ZgotmplZ 且含渐变串；
  已做变异验证（去掉 safeCSS 后该用例失败）
 2026-10-21 18:53:10 +08:00
tamakyi 27856dd4a2 字号阶梯收尾 + 主色补到 WCAG AA（新增 --tb-on-primary） 
一号事项（剩余令牌化）：
- templates/user/profile.html 20 处、base.css 9 处 font-size 全部落到 --tb-fs-*
- base.css 导航四档（0.95/0.88/0.82/0.78）合并成「桌面 md → ≤1000 xs」；logo 三档统一 lg
- 有理由保留的：.tb-pin-flag / .md-body code 的 0.9em（相对父级）、验证码 1.4/1.2rem（等宽字形）、
  chat 关闭按钮 40px、password 页 3em、mail/*（邮件客户端不保证 var()）；行内 12px/0.75rem 等值顺手换掉

二号事项（主色对比度）：
- base/default #1e87f0(3.42) → #0e6fd0(4.70)；shiroko #4a7fc1(3.69) → #3b6dac(4.74)；
  sakura #e5678f(2.80) → #ba3e66(4.70，饱和度压到 .5 保持柔和)。同色相只压亮度，目标 4.7 留余量
- 深色块 muted 之前只对 --tb-bg 算（4.7 以为过了），对压平后的卡片其实 4.31/4.17 → 提到 #a18790 / #7f8ea1
- 新增 --tb-on-primary（亮 #ffffff / 暗 #0b1016）：深色模式主色偏亮，白字只有 2.2~3.1:1，
  用同一个令牌兼顾「链接色要深」和「按钮底要深」是矛盾的。.uk-button-primary 与
  .uk-label:not(语义色) 改吃它 → 深色按钮变成浅底深字（6.10 / 8.65 / 7.27）
- 顺手封掉几处主色泄漏：header 验证码 focus、profile .feat-day.is-on、explore 随机投票的 JS outline、
  vote-results 行内色，全部改成令牌（否则换主题时不跟着变）

生成器同步：paletteVars 导出 --tb-on-primary（白字/深字择优）；?dump=palette 增加
onPrimaryCr / onPrimaryPickedBest / warnings —— 主色卡中间调时只警告不判失败；
配色面板给橙色提示。_scaffold 令牌 29 → 30。StaticVersion → 20261021c。

验证：TestSwatch 断言同步为 #ba3e66；8 种组合（base 亮暗 + 三主题亮暗）对比度全部 ≥4.5；
go test internal/{theme,templates,conf,i18n} 全绿；生成器 validate/fit/quality/palette/layers/fx/fxpipe 全过。
 2026-10-21 18:39:08 +08:00
tamakyi db4b3fa095 主题体系跟上设计令牌化：派生文字色按对比度下限、主题 muted 补到 AA 
生成器（dev/theme-builder）：
- paletteVars 的 text-secondary/text-muted 从「往底色混 36%/55%」改成 mixToContrast(5.5/4.5)：二分找最淡且达标的位置，文字本身不达标就原样返回
- 半透明卡片先 flatten 压平到底色再算对比度；参考背景取「页面底色 + 压平后的卡片」中更不利的
- 配色面板加读数（正文/次要/淡文字/主色），低于 4.5 变橙；默认 primary #4a7fc1(3.69) → #3d6fac(4.63)
- 新增 ?dump=palette 四种配色回归；README 补配色一节

主题/base（含用户本轮 base.css 改动）：
- sakura muted #a08c94(2.8:1) → #78696e(4.61)、shiroko #8794a7(2.76:1) → #656e7a(4.63)：主题覆盖令牌，基座的 AA 修复到不了主题页
- 深色顶栏链接补 secondary 覆盖：亮色块已是次要文字色，深色块原来 !important 定成正文色，同一顶栏权重跳一档
- _scaffold.css 令牌清单 23 → 29（补 fs 阶梯与 page-position），muted 说明 AA 下限
- StaticVersion 20261021a → 20261021b
 2026-10-21 17:42:43 +08:00
tamakyi 74312fba58 fix(honeypot): cleanPath 处理零宽字符，并在清洗生效时打诊断日志 
上一版只用 strings.TrimSpace，实测漏掉「看不见但不算 White_Space」的字符：
  cleanPath("\u200b/wp-login.php") = "/\u200b/wp-login.php"
（零宽没被删，还因为首字符不是 '/' 多补了一个斜杠，拼出更怪的路径）

改为 TrimFunc 同时匹配 unicode.IsSpace 与 U+200B/200C/200D/FEFF，且只处理首尾
—— 中间的零宽字符可能是攻击 payload，取证要保留原样。

另加诊断日志：清洗前后不一致时 WARN，用 %q 打出原始值。
测试环境出现过「记录里 path 带前导空白、本地链路却复现不出来」的情况，
不可见字符必须转义输出才定位得到。

测试：TestCleanPath 补零宽空格 / BOM / 中间零宽字符保留三个用例。
 2026-10-21 16:18:25 +08:00
tamakyi 846bb8a3d9 fix(honeypot): 清洗反代链路的脏路径，回环来源 IP 打配置告警 
测试环境实测（Cloudflare → nginx → 源站）发现两处：
1. 凭据文件里记录的 path 是 " /wp-login.php"（前导空格）；
2. 来源 IP 记成 127.0.0.1。

path：Match 内部会 TrimSpace 所以仍能命中，但落库与假表单 action 用的是原始
req.URL.Path —— 取证数据带脏字符，爆破脚本还可能把表单提交到错误路径。
新增 cleanPath(trim + 补前导斜杠，不改大小写) 在 Serve 入口清洗一次。

IP：记录到回环地址说明站点在反代后面但 [security] trust_proxy 未开启。
此时所有访客在源站眼里是同一个 IP：取证数据失去意义，且一次蜜罐封禁会
连带封掉整站（含普通访客）。新增一次性 WARN（24h 冷却），只提示不改行为 ——
本地直连调试时回环 IP 属正常。sample.ini 的 trust_proxy 段补对应说明。

测试：TestCleanPath / TestIsLoopbackIP 覆盖前导空格、制表符、空串、
无前导斜杠、大小写保持，以及 shared.LimitKey 折叠后的 "::/64" 形式。
 2026-10-21 15:54:39 +08:00
tamakyi c29e1d071f fix(honeypot): 补齐封禁装配与诱捕语义，凭据外置为文件不再入库 
一、封禁链路整条没接上（P0，已实测复现）
route.New 的 autoban.New 漏传 HoneypotEnabled/Threshold/Duration，而
RecordHoneypot 首行就是 `if !b.honeypotEnabled { return false }`
→ 蜜罐命中从不封禁、落库 banned 恒 false、IsBanned 永不为真。
同一批改动又把中间件里蜜罐路径的常规计数也跳过了，净效果是蜜罐路径
从「10 次封禁」退化为零计数零封禁 —— 是 regression 不是修复。
处理：抽 newBanner() 作为唯一装配入口并补齐参数；新增 banner_config_test
四个用例（全部经由 newBanner，不再自建 Banner）。变异验证：分别把
HoneypotEnabled 置 false、HoneypotThreshold 置 0，对应用例按预期失败。

二、诱捕语义（审计时漏掉，比上面更影响功能价值）
原实现对**所有方法**计数且阈值 1 → 扫描器 GET 一次假登录页就吃 403，
永远走不到「POST 提交账号密码」那一步，蜜罐的核心价值（拿到字典）归零。
处理：提交凭据 → RecordHoneypot（不受 enable_auto_ban 约束，立即封）；
纯探测 → 常规 Record（阈值 10）。新增 TestHoneypotProbeDoesNotBanImmediately，
变异验证：把 GET 也塞进 RecordHoneypot，测试按预期失败。

三、落库边界（实测取证，非推断）
- Path 原样落库而列宽 512 → PG `SQLSTATE 22001 值太长了(512)`，整条证据丢失；
  实测 600 字符失败、500 字符成功；
- 三处按字节截断 → `SQLSTATE 22021 无效的 "UTF8" 编码字节顺序`（中文密码/URL
  可稳定触发）。统一改 rune 截断并按列宽逐项对齐。

四、资源与噪音
- alerted 无界 map → 带 TTL 的 deduper（上限 2 万，过期清理 + 超限硬裁），
  同时承担告警 24h 冷却与纯探测落库采样（每 IP 每分钟一条）——
  GET 洪泛不再变成等量 INSERT；
- credentialKeys 去掉 id/name，普通 JSON 探测不再被误判为凭据提交并触发假告警；
- canary 从 meta generator 移到 HTML 注释，generator 伪装成 WordPress，
  不再同时向扫描器自曝「这是蜜罐」和「这站是 TamaBox」；
- serveLoginFailure 复用 WriteLoginPage，不再手抄响应头（已开始漂移）；
- Describer 死代码 → Prefixes()，接到新命令 honeypot paths；
- honeypot_paths 解析挪到 honeypot.SplitPaths（CLI 与 route 共用），
  补前导斜杠、拒绝 "/"（会让所有 404 变假登录页）。

五、凭据外置：数据库不再存用户名/密码
明文账号密码一旦入库就会跟着进备份、主从复制与任何能连库的报表工具，
事后无法彻底清除。改为：
- 新增 honeypot.CredRecord/CredStore：按天文件 creds-YYYY-MM-DD.jsonl，
  目录 0700、文件 0600、坏行跳过、PurgeBefore 只删整天过期的文件；
- db.HoneypotHit 删掉 Username/Password/Fields/RawBody，只留 HadFields 元数据；
- HoneypotStore 删掉 TopCredentials/ListSinceByIP（CLI 改读文件后零调用）；
- 新增 LegacyCredentialColumns/PurgeLegacyCredentialColumns：AutoMigrate 不删
  既有列，老库升级后历史明文仍在 → 启动 WARN + `honeypot purge-creds` 显式 DROP；
- 清理器 HoneypotRetention 增加 CredPurgeable 参数，与 DB 记录共用保留期；
  honeypot prune 也一并删过期凭据文件；
- CLI：hits 不再连库（DB 挂了也能查），stats 的凭据排行读文件；
- 配置 honeypot_cred_dir（缺省 data/honeypot-creds），.gitignore 加 /data/。

验证：go build ./... / go vet ./internal/... / go test ./...（含 PostgreSQL）全绿；
新增 credstore_test（追加/倒序/IP 过滤/坏行/Top/Purge/权限）、
TestHoneypotLegacyCredentialColumns（ADD COLUMN 模拟老库 → 检测 → DROP）、
TestHoneypotWritesCredentialsToFile；CLI 端到端手动验证 hits/--ip/--show-password。
 2026-10-21 15:43:25 +08:00
tamakyi 566b13eedd fix(conf): 样例配置去掉行尾注释（会被并入值导致静默失效） 
conf.Init 用 ini.LoadOptions{IgnoreInlineComment: true}，该选项的语义是
**不剥离**行尾注释：`port = 1440 ; 注释` 解析出来的值是 "1440 ; 注释"，
int 解析失败，而 MapTo 仍然返回 nil error —— 配置项静默回退零值。

实测照抄 app.sample.ini 的后果：
- text_censor_source 的值带注释，被 validateTextCensorSource 拒绝，直接起不来；
- ip_blacklist / security_alert_email 变成带注释的垃圾字符串；
- honeypot_max_rows / honeypot_auto_clean 静默失效（后者靠 sanitize 兜底才没出事）。

改动：
- 17 处 `key = value ; 注释` 改成「注释独占一行 + 裸值」，保留 CRLF；
- 蜜罐段补 honeypot_cred_dir，以及「提交凭据才封禁」的语义说明；
- 新增 TestSampleIniValuesHaveNoInlineComment：遍历所有段的键，断言值不含 ';'
  （比逐字段断言彻底，新增配置项自动纳入）。
  变异验证：给 ban_window_seconds 加回行尾注释，测试按预期失败；
- keynorm_test 补 HoneypotBanMinutes 的缺省值断言（缺省 1440 / 显式 0 交给 autoban 回退）。
 2026-10-21 15:43:13 +08:00
tamakyi d300167a30 fix(conf): 配置键名容错 + 未知键告警 + 蜜罐保留期缺省值修正 
现场故障：配置写 `honeypot_retention_days <= 30`，日志却报
「蜜罐自动清理未启用：honeypot_retention_days <= 0」。

根因（实测 ini v1.67.0 行为确认）：
1. 键名多一个 t（retention vs retain）→ ini 对未知键**静默忽略**，保留期成 0；
2. `<= 30` 这种写法让 ini 把键名解析成 "honeypot_retention_days <"
   （带尾随比较符），更加匹配不上；
3. 警告文案里写的也是错键名，等于在误导运维往错的键上配。

修复（三层）：
- 键名归一化（internal/conf/keynorm.go）：修剪首尾空白、剥掉尾随 `<` `>`
  `=` 等比较符残留，并按别名表纠正常见误拼。归一化结果必须命中该段
  合法键名白名单才会被采用 —— 不认识的键不猜，交给未知键告警。
- 未知键告警（internal/conf/unknown.go）：启动时逐段比对键名，无法识别的
  键 WARN 出来并给出最接近的合法键名建议。合法键名由反射从结构体 ini tag
  得出（单一事实来源，新增配置项自动纳入，不会脱节）。
- 缺省值语义修正（internal/conf/honeypot_defaults.go）：
  * 保留期缺省 30 天（原先零值 0 = 永不清理）；显式 <= 0 也回退 30。
    要关闭自动清理请用 honeypot_auto_clean = false。
  * honeypot_auto_clean 缺省 true。原先靠 bool 零值，ini 的 bool 解析是
    「有键才赋值」，未配置与显式关闭无法区分 → 老配置升级上来自动清理
    实际是关着的。现改用 HasKey 判定。
  * honeypot_max_rows 缺省 200000；显式 0 = 不限（会告警提醒只增不减）。
  * honeypot_threshold 缺省 1。

实测 ini 行为（探针程序，已删）：
- 键缺失或值非法时 MapTo **不覆盖**预置默认值 → 可安全预置缺省值；
- 键名大小写敏感（Honeypot_Auto_Clean 不生效）；
- HasKey 能区分「缺失」与「显式 0」；
- 段不存在时 MapTo 返回 nil 且不修改目标。

顺带清理 app.sample.ini 里的两条死配置（app.title / server.xsrf_expire）：
代码中从未读取（站点标题走 i18n），留着会让新检测对官方模板误报。

验证：
- 用现场原始配置端到端复现 → 归一化后保留期 30 天、自动清理开启、上限 20 万，
  日志明确说明「配置键名已自动纠正」；
- 误拼键（honeypot_autoclean / honeypot_max_row）自动纠正；未知键（totally_bogus）
  WARN 告警；
- 显式 honeypot_auto_clean = false 被尊重为关闭；完全未配置时缺省开启；
- 新增 TestSampleIniHasNoUnknownKeys 回归检测：官方样例配置零误报；
- go build ./... + go test -timeout 600s ./... 全绿，go vet 无输出。
 2026-10-21 13:41:19 +08:00
tamakyi 63e851ddae feat(honeypot): 自动保留期清理 + 行数上限 + VACUUM 空间回收 + size 子命令 
问题：honeypot_hits 是只追加审计表，写入完全由外部扫描流量驱动（不可预期、
不可节流），而原实现只在手动跑 CLI prune 时才清理，站点运行期表体积只增不减。

实测取证（本地 PostgreSQL 建同构表灌 10.5 万行真实数据）：
- 典型行 244 字节（含索引），10.5 万行 24 MB
- 保留期清理对照（行数恒定 10 万，每轮删 25% 插 25%）：
  有 VACUUM 22→24MB 收敛；无 VACUUM 22→52MB 持续膨胀
- VACUUM 不缩小文件，只让空间可复用；二次实测（5 万行、连续 4 轮删插）
  行数恒定 5 万、文件稳定 15MB 不再增长

改动：
- 新增 HoneypotRetention 后台清理器（每小时一轮）：时间闸 honeypot_retain_days
  + 数量闸 honeypot_max_rows，清理后调 Compact 回收空间
- db: 新增 Compact()（PG 执行 VACUUM (ANALYZE)，走 GORM Exec 非事务路径）、
  DeleteOldestBeyond()（跨方言通用）、ListSinceByIP()、Size()
- 去掉 honeypot_hits.provider 无用索引（10 万行占 648kB，全代码库零查询使用），
  并在启动时显式清理既有库上的旧索引（GORM 去 tag 不会自动删）
- 修 CLI hits --ip 过滤 bug：原先取回最近 N 条再在 Go 侧筛，导致指定 IP 的
  历史命中基本查不出来 → 改到 SQL 层过滤
- 新增 CLI honeypot size 子命令：报告行数、磁盘占用、时间跨度，并与两道闸对照
- 新增配置 honeypot_auto_clean / honeypot_max_rows
 2026-10-21 13:16:14 +08:00
tamakyi 7d52155411 fix(honeypot): 蜜罐封禁与 enable_auto_ban 解耦 + 泄露扫描后缀匹配 
- autoban: 新增 RecordHoneypot 独立通道（不受 enabled 约束）+ 独立阈值/时长；
  IsBanned 不再因 enable_auto_ban=false 而忽略已有封禁
- honeypot: 新增 honeypotSuffixes 后缀匹配，覆盖 /backup.zip、/db.sql、/id_rsa.pem
- 新增配置 honeypot_threshold / honeypot_ban_minutes
- 补测试：autoban/honeypot_test.go、route 侧禁用自动封禁仍封禁
 2026-10-21 12:36:33 +08:00
tamakyi 79051acae8 miguan v1 2026-10-21 12:09:28 +08:00
tamakyi 6c014b3ad2 修 test01：窄屏装饰全藏导致素材消失、主题名显示成 i18n key 
- 生成器：勾「窄屏隐藏全部装饰层」时给橙色警告（几层会消失）、图层行标「窄屏隐藏」、加层与导出结果再提醒；「窄屏」下拉在被全藏覆盖时标注不生效
- 新增 ?narrow=hide 复现该状态（这是「素材在手机上看不到」的头号来源：@media 把 10 槽全写 none，桌面完全正常）
- 主题名：新增 theme.DisplayName + 模板函数 themeName，i18n 未登记 theme.name.<slug> 时回退 slug；原来模板直接调用 i18n.T，缺词条就显示 "theme.name.test01"
- test01.css 删掉 @media 全 none 段：装饰是 fit 单位，浏览器会自己按视口缩，不需要这段
- StaticVersion → 20261020g（主题 css 内容变了，必须换缓存键，否则浏览器还会用旧文件）
 2026-10-20 18:23:21 +08:00
tamakyi 4bd600fb46 主题生成器：素材尺寸按视口自适应 + 导出画质可调 
- 尺寸单位 4 档：fit(按高)/fitw(按宽)/px/vh，输出 auto clamp(min(calc(100vh-24px),55%),基准,上限)，下限让位视口 → 自适应单位永不把图撑出屏幕
- fitw 补上宽幅素材：fit 只按高度缩，16:9 素材在 390 竖屏仍出 1001px 宽（照裁）
- 视口预设带高度（含 390×844）；layerMetrics 统一出 CSS/预览框/溢出检测，图层编辑区显示实测尺寸并报越界，可一键按当前视口修好
- 窄屏每层策略（原样/缩小/隐藏）+ 缩放系数；修 @media 只覆盖全局、独立配置页面在手机上从不生效的特异性 bug
- 导出画质：质量滑块（上限 0.95，Skia 在 q=1 切无损会反常）+ 长边上限，改动后从原图重算
- base.css 新增 --tb-page-position（默认 center center，旧主题不受影响），StaticVersion +1
- 新增 ?dump=fit / ?dump=quality 自检，README 与 _scaffold.css 同步
 2026-10-20 17:51:31 +08:00
tamakyi ddee221de2 feat(theme): 主题支持按页面分别配装饰，生成器改用真实页面画布 
原来的生成器只能配「背景 + 人物 + 道具」三件套，预览还是自己画的仿制页面 ——
跟真实页面不像，也没法给不同页面配不同内容。

机制层：
- internal/context.pageScope() 按路径归类，输出 <html data-page-scope>：
  box / question / admin / profile / vote（首页与 /explore 不加载主题，不列）
- /user/questions 单独归为 admin：题目列表信息密，和设置表单的装饰诉求不同
- base.css 装饰槽位 6 -> 10，背景 8 层 -> 12 层；主题按作用域覆盖时同样写满 10 个
- 新增 TestDecoSlotCount：逐文件逐声明检查 10 个值。少写一个不报错，
  只会让图层与 size/position 错位（整页重复同一张图 / 人物跑到左上角），注释守不住

生成器：
- 画板改成 iframe 加载 outputs/preview-*.html（真实模板渲染），配 serve.py 起本地服务
  解决 file:// 下父页面读不到 iframe DOM 的问题
- 八个页面作用域（去掉不生效的首页/探索），每个可独立配背景与最多 10 层装饰
- 图层类型：图片 / 径向光斑 / 线性光；9 宫格锚点 + 像素偏移，可在画板上直接拖
- 位置统一写 calc(0%|50%|100% ± Npx)：百分比是相对 (容器-图片)，
  不用 left/bottom 关键字混搭，避免三值语法非法导致整条声明作废
- 配色只填 6 个基础色，其余 4 个必需令牌按方向派生（surface-2 往 text 靠，
  浅色变深、深色变亮，方向自动正确）

配套：
- zz_preview_test.go 增加单题页 / 题目列表 / 投票页预览，作为生成器画板
- docs/theme-page-scope.md 记录作用域取值、选择器特异性与 10 槽位约束
- StaticVersion 20261020e（base.css 变了）

验证：生成器导出的 CSS 通过 TestThemeCSSComplete + TestDecoSlotCount；
真实箱主页计算样式为 12 层对齐；临时主题验证「question 覆盖为 none」生效、
未覆盖时回退全局。
 2026-10-20 10:53:44 +08:00
tamakyi 15aebd6d19 theme(shiroko): 换前景空地的场景，补自行车/步枪，修耳朵与白孔 
部署反馈三个问题：
1. 狼耳顶端被削平——上一版用矩形抹光环，矩形右下角切到了左耳尖。
   改成只抹光环的非白连通域（与头发不连通，bbox 291,93-584,232），耳朵完整。
2. 手内侧 / 大腿内侧白没抠干净——那是环状闭合的白色区域，四角 floodfill 进不去。
   新增封闭白孔检测（>=246 且不与边缘连通，面积 >=40）整块掏空，袜子（237）不受影响。
3. 人物像站在课桌上——原场景前景全是课桌，脚下没有地面。
   重出场景：前景是空地，课桌退到右后方；人物脚下是地板 + 接触阴影。

同时补上她的自行车与步枪：独立素材 props/bike.webp，镜像成车头朝右与人同向，
放在人物身后偏左（第一层是人，车在第三层，天然被她遮住），视口变化时两者同步移动。
静态版本 20261020d
 2026-10-20 09:29:09 +08:00
tamakyi 2e9bd6bb73 theme(shiroko): 重画光环——AI 给的环形状歪、环内还糊着白孔 
- 旧环是非白像素的独立连通域（bbox 291,93-584,232，与头发不连通），整块抹白后重画
- 新环：-7° 倾斜椭圆，100x34，线宽 10px，4 倍超采样 + LANCZOS 求平滑，外加 45% 模糊柔光
- 关键：环是在 alpha 建好之后再画的，环心天然透明，不再需要给封闭白孔补洞
- 压白 16% 与场景保持一致；静态版本 20261020b，图片另带 ?v=20261020b
 2026-10-20 08:28:39 +08:00
tamakyi fb94b8c204 theme(shiroko): 补四层空气层——窗光/暖散景/地面光斑/底部压深 
场景压白 38% 后整页亮度只剩 235~246，直接摆物体会突兀，改用纯渐变造光：
- 左窗光柱 linear-gradient(112deg)
- 右侧一朵 120px 暖散景，给右侧空白一点体积
- 人物脚下 560x170 地面光斑，把人物钉在地上
- 底部 24% 轻压深，页面下沿不飘

实测亮度差 3~9 级（肉眼可辨但不刺眼），横向扫描相邻像素差 max 4，无色阶断层。
纯白散景压在压白场景上不可见（diff 0.14），提亮必须先有暗部。
静态版本 20261020a
 2026-10-20 01:13:59 +08:00
tamakyi e95671f2fe theme(shiroko): 人像换成侧后方窗边背影，压白 16% 融入场景 
- 盘腿坐的正面人像在空教室里像贴纸：直视访客、没有环境、配色比场景饱和
- 新素材 chibi/window.webp：侧后方视角、双手背在身后望向箱内，抠白底后压白 16%
  与压白 38% 的场景同一雾度；配椭圆接触阴影，脚踩地面不悬空
- 尺寸 380->400px，接触阴影同步复位；静态版本 20261019r
 2026-10-20 00:05:01 +08:00
tamakyi 33e31cf4dc theme(shiroko): 按二次元官网构图重做——整页场景 + 悬浮磨砂 UI 
参考蔚蓝档案 JP 首页（bluearchive.jp）的做法：整个视口是一张场景插画，UI 浮在场景之上，
而不是"白底 + 留白里贴几个人物"。之前几版反复调摆位都显得怪，根源就是缺了这层场景——
人物没有环境，怎么摆都是贴纸。

- 新增教室场景两张（1920×1080 / 720×1003，共 28KB）：生成后裁掉右下角水印、
  混白 38%、模糊 1.4px，保证白卡片仍有对比度；
- 卡片与顶栏改半透明白 + backdrop-filter 磨砂（深色关闭，背后没场景时半透明只会变浑）；
- 人物站在场景左侧地面（340px，离底边 36px）+ 椭圆接触阴影；
- 浅色不再叠平铺纹样（压在实景上会变噪点），pattern.svg 删除，深色保留 pattern-dark；
- 顺带修 ruleBody 不剥 CSS 注释的缺陷：令牌前写注释会让 tokenValue 取到粘连键，
  色块预览静默失效（新增 TestRuleBodyIgnoresComments 守住）；
- StaticVersion → 20261019q
 2026-10-19 23:01:55 +08:00
tamakyi 2f2e00ad65 theme(shiroko): 装饰改为「半隐在卡片后」的单人 + 接触阴影 
按选定方向收敛：

- 只留 sit 一个角色，左移 515px 让右侧约 40px 钻进卡片底下（卡片定宽 750 居中，
  左沿 = 50% - 375px），被卡片挡掉一部分才有空间关系，不再浮在留白中间；
- 离底边 26px（脚踩最后一像素像被裁掉），配一层椭圆径向渐变当接触阴影，避免悬空；
- 纹样透明度 0.13 → 0.085（深色 0.09 → 0.055），图案 url 补 ?v=；
- 收掉另外三个人物与第一层半透明立绘；
- StaticVersion → 20261019p
 2026-10-19 21:43:44 +08:00
tamakyi 59ffcb5096 theme(shiroko): 纹样按三行均布，消除横向条纹 
图案元素原先全挤在每个 tile 的上半部（雪花 52 / 光环 62 / 点 150、176），
铺开后在整页形成明显的横向条纹带 —— 这也是"看着怪"的一部分。

- 元素改为 3 行均布（52 / 132 / 152-212），tile 340px 时不再有空白横带；
  实测左栏 60px 带宽均值由 245→237→249（跳变 12）收敛为单调 245→236。
- 图案加 ?v= 版本：图片不走 StaticVersion 的缓存键，否则老访客最多 24h 看到旧纹样。
- StaticVersion → 20261019o
 2026-10-19 21:32:48 +08:00
tamakyi 3717b77ef8 theme(shiroko): 装饰改为一组两人，去掉散射与半透明立绘 
四角各摆一个人读起来像贴纸墙纸：人物之间没有位置关系，也没有和内容的关系，
右下角还会和右对齐的页脚文案（社区规则 / 备案号）挤在一起。

- 只留左下角一组：盘腿坐（330）+ 挥手（190），贴住左边缘和下沿；
  990px 以下缩小并整体左移，900px 以下（卡片占满宽度）不出人物，顺带省掉图片请求。
- 删掉 16% 透明度的 hero-fade 叠层：虚实两套人物叠在一起像重影。
- 纹样减到雪花 + 光环 + 两点，透明度 0.2 → 0.16，tile 320 → 340。
- 卡片压在近白底色上分不清边界，补一圈 1px 冷调描边（box-shadow，不占布局）。
- StaticVersion → 20261019n
 2026-10-19 21:19:36 +08:00
tamakyi a6059bec1b theme: 启动日志暴露未登记的主题 
新增主题后忘了写进 [theme] available，表现只是"设置页里找不到"，
日志里没有任何痕迹。现在启动时会打：
- info  主题注册表已加载 enabled=...
- warn  [theme] available 未登记以下主题 themes=shiroko available=...

discover() 用 fs.Glob 扫内嵌 css/themes/*.css，按 slug 规则过滤掉 _scaffold.css。
示例配置补上 shiroko，文档补「部署后看不到主题」的两步排查。
 2026-10-19 21:05:46 +08:00
tamakyi 0c39afff3a theme v4: 装饰层 + 砂狼白子 Q 版插画 
- base.css 新增装饰层令牌 --tb-deco / -size / -position：固定 6 个槽位、固定像素四角定位，
  不受 cover 裁切影响（竖屏桌面会把贴边的插画切掉）。多层背景的列表长度必须恒定，
  值一多一少会整层错位（表现为整页重复同一张图）。
- shiroko：4 个 Q 版人物（wave/cheer/think/sit/doze），以用户立绘为参考图 image-to-image
  生成后抠白底；左右各两个、立绘在右下当水印。顶部用固定 96px 避开顶栏，
  真实视口 ≥920px 才补中间两个，矮屏不放（否则与立绘重叠）。
  深色关掉装饰层，图案改为几何纹样。
- sakura：顶栏取页面底色、顶栏链接提到次要文字色、uk-alert-primary 改粉底。
- 主题注入补上 /user 后台与 /vote 投票页（跟随箱主/发布者的语言与配色）。
- StaticVersion → 20261019m
 2026-10-19 20:37:28 +08:00
tamakyi 38cd41afde theme v3 2026-10-19 16:46:42 +08:00
tamakyi 3202ef9821 theme v2 2026-10-19 16:16:07 +08:00
tamakyi e9fba8b9ed theme v1 2026-10-19 15:23:11 +08:00
tamakyi 86dc8384bc 全局美化 v5 2026-10-19 12:44:32 +08:00
tamakyi 6789193052 fix footer 2026-10-19 10:09:57 +08:00
tamakyi 899b6d7f32 fix v16 2026-10-19 03:01:17 +08:00
tamakyi dba991aa9d fix v15 2026-10-19 02:37:59 +08:00
tamakyi 12a37e726f fix v14 2026-10-19 02:25:19 +08:00
tamakyi 4592b6ef24 fix v13 2026-10-19 01:58:00 +08:00
tamakyi bd613a6f5a fix v12 2026-10-19 01:11:28 +08:00
tamakyi 8a0e58734c restrict v10 2026-10-19 00:30:46 +08:00
tamakyi efd5fce9a7 restrict v10 2026-10-19 00:07:22 +08:00