0 Fork 0

Files

T

admin c1b5e4d966 chore(工作区): 全量入库 + 补齐 .gitignore（以工作区为准）

- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次）
- .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…），
  目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪
- .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/）
- .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*）
- .gitignore 补：备份件（*.bak-*）
- 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）

2026-10-10 23:13:22 +08:00

170 KiB

Raw Blame History

2026-09-19 工作日志（DSH 覆盖网络线）

00:15 – 01:0x · 序㊽执行棒 —— 修「重启 worker 后实例端口注册丢失 / 孤儿端点条目不自愈」

任务：让探针 OBS-09 由 SKIP 回到 PASS（automation 7dba0a2c-6cd4-456a-be0c-c53df4ac0d95）。

结论：修复落地并上生产，探针 26 PASS / 2 FAIL / 1 SKIP → 29 PASS / 0 FAIL / 0 SKIP（rc=0）。

根因（文件＋行） —— 不是 spawn 流程、也不需要重启实例：

src/worker/agent.ts:256-264（改前）reconcileTunnel() 早已存在，但 live 只取 spawner.listUserInstances()；
src/supervisor/orchestrator.ts:558-560 它是 return [...this.mains.values()] = 本进程 launch 过的；
src/supervisor/orchestrator.ts:290 认领来的 scope 刻意不进 mains（launchToken 不可恢复，见文件头序㉕）⇒ 上一进程遗留的实例端口没人重新声明；
src/net/relay/server.ts:2151-2203 dropSession() 只摘会话、不删条目；server.ts:1447-1466 onPortChange(add=true) 走 ensureEndpoint() 复用既有条目 ⇒ 重登记 = 就地覆盖孤儿。
🔴 交接单 §14-7 那句「恢复路径须'实例重新拉起'」被本棒实测证伪。

改动（2 个源文件）：

src/supervisor/orchestrator.ts：新增 adoptedInstancePorts()（只报 alive === true 且带端口的认领记录）＋ onRehydrateSettled 落定回调（pendingProbes / rehydrateScheduled 计数，settleRehydrate() / maybeRehydrateSettled()），rehydrateAdoptedScopes() 三个出口都落定，probeAdopted() 补射。
src/worker/agent.ts：对账口径改为 listUserInstances() ∪ adoptedInstancePorts()；抽出 tunnelTick() 供 20 s 定时器与回调共用；装配回调。
⛔ 未绕过既有准入：仍走 forward() → addPort() → PORT_ADD → onPortChange（含窗口校验＋ worker 侧 allow）。

零回归三件套（终态）：探针 29P/0F/0S（rc=0）｜npm.cmd test 200 pass / 0 fail / 1 skipped（Node v22.22.2）｜--scene all 12P/0S/0F（rc=0，6m01s，幕4-C 27087 ms/30000）｜➕ node --test test/orchestrator-rehydrate.test.mjs 18/18（该文件刻意不进 npm test）。

部署：包 dshs-lib-seq48.tgz（685,368 B / 270 文件，md5 a902c936cefdeeb3eb13c67dfcb5dd00）→ 两机 4 处 lib 全量替换，270 × 4 = 1080 对 md5 不一致 0 / 缺失 0；回滚点 /opt/dsh/backups/seq48-20260919-0030/（282/281/282/281 文件）。 ⚠️ 自造偏差（如实）：首轮"两机同窗口"脚本把 cd 写进后台复合命令内 ⇒ 106 未执行、47 已落地 ⇒ 实际窗口相差 ≈ 28 s（47 00:30:47 / 106 00:31:15）。改动为纯 worker/supervisor 侧增量（无协议帧 / 无接口形状 / 无 env 变化）⇒ 无跨版本不兼容，未回滚重做。

中断记录：🔴 未为验证重启任何实例；唯一服务中断 = 受控对照中 dshs-worker 停启一次（停用 ≈ 5 s，实例与用户面全程未动）。

遗留（已登记交下一棒）：🔴 观测面单一 —— OBS-01/OBS-08/OBS-09 的绿取决于 106 worker 挂在哪台中继（探针只读 47 的 RELAY_STATUS_URL），而通道按抖动换址 ⇒ worker 一旦落到 106 自家中继三项再红/SKIP；⚠️ 死口孤儿未回收（替换后旧端口条目永久 online=false）。

产物落点：交接单 覆盖网络-序45-低熵块治理-测熵与实现.md §15（§8 前前缀 be548afc3340583b2b63ca254bcf550f 逐字不变）＋参数表 §11.15（§10 现算 ac6bbbbb8c92bd57ff0dc4cd8f4983ba 同值）＋接续入口 §0/§2。

收口时现场观测（00:52:37 · ⛔ 如实） —— §15-10-1 那条遗留当场复现：106 worker 又按抖动路径挂回了 106 自家中继。⇒ 47 relay used=1、eps=[('w-106',19000,False),('w-106',21001,False)]（两条离线孤儿）；106 relay used=1、eps=[('w-106',19000,True),('w-106',21001,True)]。✅ 修复有效（106 侧两条都在线，含实例面 21001 = 改前 106 侧只有 19000）｜⚠️ 探针的绿不稳固（此刻复跑会回到 ≈26P/2F/1S）。🔴 录取的 29P/0F/0S 是 00:35:59 / 00:46:33 两次实测真值（worker 当时挂 47），⛔ 未为凑绿重启 worker。全部机器单元 active。

下一棒：序㊾执行棒（探针观测面按两台中继取并集），automation 2febff6b-5786-46a3-b345-b648f2e19df3（一次性 · 2026-09-19 01:03 = 收口 +~6 min；⚠️ 因收口晚于预估，已从 00:55 顺延）。📌 在册待拍板项仍 = D8（云安全组乙-1）。

01:0x – 01:4x · 序㊾执行棒 —— 修「探针观测面单一」：`OBS-01`/`OBS-08`/`OBS-09` 数据源改「两台中继并集」

做了什么（单文件六处 · ⛔ src/** 零改动）：scripts/overlay-probe.cjs 新增 readPeerView()（对端 106 /status 的唯一取数入口：真机一次 ssh 取 /status 原文＋ __RELAY_ACTIVE__ 哨兵，缓存一份供并集与「空表可分」共用）／mergeEndpoints()（键 = network:hostId:port，online 取或，localPort 取在线那一侧）／unionUsed()（= network/hostId 去重后的并集基数，⛔ 非求和）／remoteInstanceCodes()（🔴 实例探活分机做 —— 归属 106 的端点其回环落点只在 106 上存在）＋三条判据换数据源＋ classifyEmptyView() 收敛。🔴 阈值 / 派生规则 / 判据形态一字未动（并集只消除"看不见"）。

先红后绿（三条证据）：(a) 夹具两腿（同一份真实 /status ＋真实 ss/nft ＋参数表副本 SSH_TARGET_*=127.0.0.1/SSH_PORT=1）只差是否给对端那一半 ⇒ 红 rc=1（FAIL OBS-08 离线 2 条｜SKIP OBS-09）→ 绿 rc=0（PASS 离线 0 条｜PASS w-106:36873=401），逐行 diff 只差 2 行。(b) 真机漂移态（--scene all 后现场恰是 47 视角空：47 used=1/ep=[]、106 两条 online）⇒ PASS OBS-01 used=2／PASS OBS-08（47 0 条＋对端 2 条）／PASS OBS-09 w-106:40701=401（🔬 探的是 106 机上的落点）。(c) 真机退化腿（对端不可达）⇒ FAIL OBS-01 used=1／FAIL OBS-08 离线 2／SKIP OBS-09 = 改前 47 单点判法（⚠️ 另带 4 条与并集无关的红：OBS-18/21/22/23 本就要 ssh 到 106）。

硬约束③（先核后做）：对 47 /status 的读取次数一次未变（仍三次）；对端那份在第三次采样之后 ⇒ ⛔ 不进 OBS-16 门窗口；隔离实验原文 = 47 statusHits 5→6 (Δ=1) 而中间插了 2 次读 106（106 自身 2→3）⇒ ✅ 读 106 不动 47 的计数器。

零回归三件套：探针 29 PASS / 0 FAIL / 0 SKIP（rc=0；漂移态那次 28P/1F 的唯一红 = OBS-04 identityOk=1 = 演练重启 47 relay 的计数余波）（①）｜npm.cmd test 200 pass / 0 fail / 1 skipped（# tests 201；Node 22.22.2）（②）｜--scene all 12 PASS / 0 SKIP / 0 FAIL（rc=0；6m10s；幕1-A 15386ms / 幕4-C 19650ms）（③）。

部署：47 /opt/dshs/scripts/overlay-probe.cjs：eaec1ad560adbec37a15cd145a5ebb77（109266 B · 序㊳期陈旧）→ d2f879dc3220f2800d812437518e3c63（135215 B）；106 /opt/dshs-cluster/scripts/overlay-probe.cjs 此前无此文件 ⇒ 新落同 md5（两机同源，免日后跑出旧口径读数）。⛔ 零新增监听口（该文件不被任何单元读取）。

生产动作（R8 · 动手前已声明）：两机 scripts 落点更新＋ --scene all 演练＋收口处置 = 停 106 dshs-relay 45 s 后起（逼 worker 回落 47；⚠️ 首轮"停 3 s"不足够 —— 106 是该 worker 候选链第一条）。⛔ 未重启 worker、⛔ 未换实例、⛔ 零不可逆动作。

两条如实留档：(a) 本机无改前那份的字节级副本（工作树未提交、开工未做 .bak；HEAD 版 114850 B ≠ 改前 122541 B）⇒ 回滚依据 = 交接单 §16-2 改动清单｜(b) 47 落点旧副本被就地覆盖（陈旧、代码仓内有更新版本 ⇒ 判无损）。

遗留（未被本棒结清）：🔴 D8 云安全组乙-1（只能你在云控制台落地；两机＋本机均无云凭据）｜⚠️ 死口孤儿仍未回收（并集只消除"看不见"，online=false 条目仍留表；回头条件 = 出现端口替换后 OBS-08 再红）｜⚠️ OBS-04（identityOk ≥ 2）对中继重启敏感（计数归零，需一次回落动作才回绿；既有口径）。

产物落点：交接单 覆盖网络-序45-低熵块治理-测熵与实现.md §16（§8 前前缀 be548afc3340583b2b63ca254bcf550f 逐字不变；全文 md5 324b17dff8982e1fd42f09e3301ac463／619 行）＋参数表 §11.16（§10 现算 ac6bbbbb8c92bd57ff0dc4cd8f4983ba 同值；全文 md5 11ca55a3d1c63702a1f6931412f359e7）＋接续入口 §0/§2 ＋证据目录 _tmp_seq49/。

下一棒：⏹ 无 —— ⛔ 未登记（判定 = 本线可停）：唯一在册红 D8 只能你侧控制台落地（挂起中）；「死口孤儿回收」的回头条件未触发且属 worker↔relay 接口级改动 ⇒ 应由规划棒先行，而"要不要现在开这条规划"属业务优先级（边界外①）。

05:3x · 序㊾收官提交 —— `d2ef362` 入仓（双推 1/2 成功）

动作：用户单条指令「提交到仓库」。抢全局执行锁（提交到仓库-序㊾收官）→ 暂存 → 提交 → 双推 → 释锁。

提交：d2ef362（父 45b4999）· 20 文件 · +2998 −183 · 分支 master。范围 = 本棒＋前几棒已部署未入仓的源码/文档：scripts/overlay-probe.cjs／scripts/dshlog.mjs／scripts/overlay-entropy.cjs／src/net/relay/content/*.ts／src/net/relay/{index,main}.ts／src/supervisor/orchestrator.ts／src/worker/agent.ts／test/overlay-content.test.mjs／dsh-server-docs/04-调整方案/129·133／dsh-server-docs/交接单/覆盖网络-序45-…md／INDEX.md／docs-manifest.json／skills/*／交接单/README.md。⛔ 未用 git add -A —— 显式排除仓库根三个临时目录（_tmp_seq24/、_tmp_seq40/、_中间产物_待清理/）。

双推结果：① 原仓 work.alotbuy.com:maogeigei/dsh_shenxian.git ⇒ ✅ 45b4999..d2ef362 master -> master；② CNB https://cnb.cool/maogeigei/dsh-shenxian.git ⇒ ❌ Repository Not Found / 仓库不存在。

🔴 根因已取证（⇒ 不是路径问题，⛔ 别改 URL）：GET https://api.cnb.cool/user 带本机 ~/.cnb/token（94 字符）⇒ HTTP 401 errcode:16 The credential is invalid or expired —— 与既有记载「CNB 令牌过期时回泛化『仓库不存在』」完全一致。补救（需用户侧动作）= 重新授权 CNB 连接器（刷新 ~/.cnb/token）或按 ~/.cnb/git-cred.sh 头部注释生成长期令牌写入 ~/.cnb/git-token。

⚠️ 顺带纠正一条易误用：~/.ssh/config 里 work.alotbuy.com = HostName 154.40.35.3 / Port 222 ⇒ 对该仓 ⛔ 不要套「ssh 一律 -p 22」（那条只适用于 47/106）。实测：强制 -p 22 ⇒ Could not read from remote repository；裸 git ls-remote origin ⇒ 正常。

产物落点：证据 _tmp_seq49/commit_msg.txt、_tmp_seq49/tokencheck.mjs（只打印状态码，⛔ 不含令牌明文）。

05:4x · CNB 长期令牌落地 —— 双推两腿恢复

动作：用户提供长期令牌（名称「开发项目」· Git 用户名 cnb）⇒ 写入 ~/.cnb/git-token（helper ~/.cnb/git-cred.sh 的首选取值位；⛔ 未改远端 URL、⛔ 未动 ~/.cnb/token 那份连接器登录态）。

验证链：令牌有效性 ⇒ api.cnb.cool/user 由 401 credential invalid or expired 变为 403 errcode:10023 Missing required scopes: account（= 令牌有效，仅未勾 account 域；git 用途不需要该域）｜ls-remote https://cnb.cool/maogeigei/dsh-shenxian.git ⇒ 由「仓库不存在」变为正常返回裸 sha。

补推结果：git push origin master ⇒ 原仓 Everything up-to-date；CNB 45b4999..d2ef362 master -> master。复验三处裸 sha 全等：原仓 = CNB = 本地 = d2ef362a984fce710e4f46dc8cc1c09cfa6f6b19。git remote -v 的两条 pushurl 未被挤掉。

沉淀：MEMORY.md 该条改为「会过期（09-19 实测 401 ⇒ 回泛化『仓库不存在』，⛔ 别改 URL）＋ 已落长期 ~/.cnb/git-token」；🔴 令牌明文不入任何记忆/文档，只落在 ~/.cnb/git-token。

06:0x · 域名迁移（alotbuy.com → ai1net.com）—— 取证＋可做项全部就位，卡在 CF 凭据

用户指令：把线上部署的服务域名从 alotbuy.com 改为 ai1net.com。本轮零生产切换（⛔ 未启用新 vhost、⛔ 未动 /etc/dshs.env、⛔ 未重启任何单元）。

现状取证（47）：门户 alotbuy.com.conf（alotbuy.com www.alotbuy.com *.alotbuy.com → 127.0.0.1:3080，/dshs-relay → 20080，证书 live/alotbuy.com = SAN alotbuy.com ＋ *.alotbuy.com）｜实例子域 = <user>.alotbuy.com（一级标签，由门户块的 *.alotbuy.com 承载，无需第二张证书）｜旧名 301 块 dsh.alotbuy.com.conf｜中继兜底 relay-direct.conf（把 Host 改写成 alotbuy.com）｜env = DSHS_BASE_DOMAIN=alotbuy.com / DSHS_COOKIE_DOMAIN=.alotbuy.com / DSHS_SECURE_COOKIES=true / DSHS_PORT=3080｜中继种子内置 ['https://alotbuy.com/dshs-relay']，env 覆盖键 = DSHS_OVERLAY_BOOTSTRAP_SEEDS（splitList，可多值 ⇒ 可加性加 ai1net）｜证书链 = certbot 1.22.0 ＋ dns-cloudflare 插件，凭据 /etc/cloudflare.ini（bare line，无 section 也能被 certbot 读）。

两条关键实测（直接决定方案）：

🔴 /etc/cloudflare.ini 令牌只覆盖 alotbuy.com 一个 zone（GET /zones 仅回 1 条）⇒ 写不了 _acme-challenge.ai1net.com ⇒ *.ai1net.com 通配证书签不出来（LE 通配只认 DNS-01）⇒ 阻塞 = 需用户给 ai1net 域凭据（CF API 令牌，或 CF 面板签发的 Origin CA 证书）。
🔴 CF→源站协议实测 = 明文 http:80：临时探针（server{listen 80; server_name ai1net.com; return 200 "SCHEME=$scheme XFP=$http_x_forwarded_proto"}）经 CF 取回 SCHEME=http / XFP=http；同时 https://ai1net.com = 526（源站 443 对 SNI=ai1net 返回的是 *.alotbuy.com 那张证书 ⇒ 主机名不匹配）。⇒ ai1net 的 CF SSL 模式必须先切 Full (strict)，否则启用门户 80 代理块 = 凭据裸奔（与 alotbuy 版"必须 Full(strict)"的设计前提相悖）。

可做项已全部就位（均未启用**）** —— 47 /www/server/panel/vhost/nginx/_pending-ai1net/：

ai1net.com.conf（md5 前8 13d9b874 · 6643 B）＝与 alotbuy 版逐字同构＋ /dshs-relay ＋ ACME webroot location（^~ /.well-known/acme-challenge/，DNS-01 与 http-01 两路续期都不断链）
relay-direct.ai1net.com.conf（8cb8a057 · 2737 B）＝中继兜底，Host 改写已指 ai1net.com
RUNBOOK-cutover.md（39305a3f · 6254 B）＝ S1–S5 逐步＋每步验收＋回滚＋影响面
✅ nginx -t 仍通过（BT 只 include nginx/*.conf 一层，子目录天然不生效）；🚫 探针 conf 与 3 处标记文件已全部清理；门户 alotbuy.com 仍 200；零中断。

待用户侧（两条，缺一不可）：① ai1net 域 CF 凭据（API 令牌 Zone:DNS:Edit 限 ai1net.com，或 Origin CA 证书）② ai1net 的 CF SSL 模式 = Full (strict)。⚠️ 另：旧域退役（alotbuy.com → ai1net.com 301）本轮不做，留待确认时机。

ai1net 侧 DNS 已逐条验通（2026-09-19 06:0x）：在 47 默认 80 根放一个标记文件（⛔ 无需改任何配置、无需 reload），经 CF 分别取回原文 ⇒ ai1net.com / www.ai1net.com / relay-direct.ai1net.com / probe.dsh.ai1net.com 四条全部命中 47（标记文件随后已删）。⇒ DNS 这一环无需任何改动（含实例子域形态）；缺的只有证书 + CF SSL 模式 + 47 侧切换。

产物落点：本机 域名迁移_ai1net_20260919/（pending/ = 两份 vhost ＋ RUNBOOK；另 recon47*.sh / probe47*.sh / probe_scheme.sh / cleanup.sh / vhosts_dump.txt 为取证脚本与原文）；远端 47 /www/server/panel/vhost/nginx/_pending-ai1net/（同 3 个文件，md5 一致）。

⚠️ 勘误（06:1x · 用户回「已经设置」后复验） —— 本条此前把 CF SSL 模式列为「必须切 Full (strict)」，判据用错了：

实测复验：http://ai1net.com/<标记> 仍取回原文（⇒ http 访客时 CF→源站走 HTTP:80）而 https://ai1net.com = 526。
两条证据合并只与一种解释相容：https 访客时 CF→源站走 HTTPS 且在校验证书（526 正是该校验的产物 ⇒ 模式本已是 Full (strict)，Flexible 下 https 访客会 200）。⇒ 该项无需用户再做。
与 alotbuy 的真实差别只在「Always Use HTTPS」：alotbuy 开着 ⇒ http 访客被 CF 边缘 301 掉、源站 80 永不被用到；ai1net 没开 ⇒ http 访客可走明文回源。⇒ 改为可选建议（非阻塞）：要安全等价就开 Always Use HTTPS。
🔑 教训：「CF→源站明文」这条判据只对"http 访客"成立，不能推出 zone 模式；判 zone 模式要看 https 访客的返回（526 vs 200）。

06:1x–06:4x 域名切换已执行完成（alotbuy.com → ai1net.com）＋执行中发现并修掉两个真问题

用户给了 CF API 令牌（cfut_w6YJ…，落 /etc/cloudflare-ai1net.ini mode 600；/zones 自检 = 可管 zone 1 = ai1net.com）⇒ 按 RUNBOOK S1→S5 一次做完，每步有验收与回滚点。

一、五步执行（全部 ✅）

步	结果
S1 证书	`certbot certonly --dns-cloudflare` ⇒ `Successfully received certificate.`；`CN=ai1net.com`／issuer `Let's Encrypt YR1`／`notAfter Dec 17 21:16:42 2026`／SAN 含 `.ai1net.com`；复用既有 ACME 账号 `63fe5a37…`；自动续期任务已建*
S2 vhost	两份 vhost 入 `/www/server/panel/vhost/nginx/`（`nginx -t` 失败即 `rm -f` 自回滚）；`https://ai1net.com/portal.html`=200、`dsh.ai1net.com`=200、SNI=`CN=ai1net.com`
S3 env	备份 `dshs.env.bak-dom-20260919-061626`(684B)；`BASE_DOMAIN=ai1net.com`／`COOKIE_DOMAIN=.ai1net.com`／`SECURE_COOKIES=true`；restart ⇒ active＋`registered host=manager`
S4 连带	`relay-direct.conf` Host→`ai1net.com`；`dsh.alotbuy.com.conf` map→`ai1net.com`/`$label.ai1net.com`；四验收点全绿
S5 worker	不是可选项，是必须项（见下）

二、端到端验收（真实链路 + R4 临时会话）

门户 https://ai1net.com/portal.html = 200 / 50726 B / title=管理门户（与 alotbuy 逐字节同源同大小）。
admin.ai1net.com（w-47 归属）⇒ 302 → ?token=…（实例已就绪）；guest.ai1net.com ⇒ 302 → ai1net.com/wake.html?next=…；无 cookie ⇒ 302 → ai1net.com/login.html。临时会话 DELETE 1、残留 0。
三处 /dshs-relay 响应逐字一致（dshs relay: WebSocket upgrade only）。
零回归：探针 29 PASS / 0 FAIL / 0 SKIP（rc=0）（OBS-21：dshs@47 与 dshs-worker@106 均 count=5 hosts=5）｜npm test 201/200/0/1（与基线逐字同）。

三、🔴 执行中发现并修掉的两个真问题

（甲）DSHS_OVERLAY_BOOTSTRAP_SEEDS 双载体冲突 —— 我引入的回归。 S3 原脚本把它重复追加进 /etc/dshs.env；而 /etc/dshs.env（EnvironmentFile）压过 drop-in 的 Environment=（dshs.service.d/overlay-443fb.conf 明写「入口列表的唯一载体」）⇒ 生效列表被窄化成 2 条且同落 47 一台中继，丢掉 relay-direct.* 与 106.54.21.172 ⇒ Manager 失去对 106 的拨号会话。 ⇒ 修：删 /etc/dshs.env 里的重复键；drop-in 列表升级为 5 条（ai1net（主）＞alotbuy＞relay-direct.ai1net＞relay-direct.alotbuy＞106.54.21.172），地址覆盖加 relay-direct.ai1net.com=47.77.182.89。备份 = overlay-443fb.conf.bak-dom-20260919-063350(2124B)、dshs.env.bak-seeds-20260919-063350(772B)。生效自证 = /proc/<dshs pid>/environ 逐字为新 5 条。

（乙）w-106 用户实例子域 500 解析不出落点 —— 既有缺口，被验收照出来。 机理（文件级）：RelayRendezvous.resolve()（lib/net/relay/rendezvous.js:23-47）取 presence() ?? online()；online 只来自单一 DSHS_RELAY_STATUS_URL = http://127.0.0.1:20080/status（47 中继），而 w-106 的实时在线态在 106 中继上（106 /status 原文 online: ["w-106(session=… ports=19000/21001 …)"]），47 那份是 online:false 的陈旧条目 ⇒ resolve() 返 undefined ⇒ agentBaseUrlOf() 按设计拒绝回落到 endpoint（P0-3：relay 语义下回落会打到控制面本机同号端口）⇒ 500。 ⇒ 修（S5 正好覆盖）：给 106 worker 一份以新域为主入口的 SEEDS ⇒ worker 把主入口落回 47 中继注册 ⇒ 47 /status 该端点 online:false → true ⇒ 解析恢复（guest.ai1net.com 由 500 → 302 wake.html）。106 备份 = dshs-worker.env.bak-dom-20260919-063515、dshs-relay-client.service.bak-dom-20260919-063515；106 残留旧域引用已清零（除种子兜底保留 alotbuy）。 ��️ 该 500 在"恢复 5 条候选"之后仍复现 ⇒ 不是（甲）单独造成的；真正修好它的是 S5。这一条排除了「种子窄化 = 500 唯一根因」的假设（★ 值得记住的排障顺序：先恢复配置到"更多候选"再复测，能一刀切开"配置窄化"与"既有缺口"）。 🔴 遗留（未修 · 已上报）：worker 一旦按抖动漂到 106 自家中继，47 中继即再视其离线 ⇒ 同一 500 会回来，而探针此刻仍全绿（序㊾让它按并集看 = 观测面绿、控制面红）⇒ 正解 = 把「两台中继并集」这条口径从探针推广到控制面，属独立立项，本轮未动（依「只做被明确要求的事」只报告）。

四、边界自证

⛔ 未 commit / 未 push（本轮零源码改动，只改服务器配置）｜⛔ 未改 package.json｜⛔ 零新依赖｜🔴 未改参数表值格｜⛔ 未调 RELAY_FAILOVER_DEADLINE_MS／HB_SEC／burst、⛔ 未禁用 COOLDOWN_MS=0｜⛔ 未新增公网监听口、⛔ 未动 nft｜⛔ 未删数据｜✅ 令牌明文不入任何记忆/文档（只落 /etc/cloudflare-ai1net.ini 600）。

五、⚠️ 旧域退役（未做 · 待你确认）

alotbuy.com 侧保持原样可用（门户 200、<user>.alotbuy.com 落到门户壳）。未加 alotbuy.com → ai1net.com 的 301 —— ① 属"额外发现即先报告后动手"；② 保留旧域原样 = 软回滚路径（只改 DSHS_BASE_DOMAIN 即可退回，不必同时撤 nginx）。⇒ 何时退役（或要不要加 301）待你定。

07:0x–07:1x 用户拍板两条 → 取证完成但锁被占 · 未落地

用户拍板（原话）：「1、旧域 alotbuy.com 怎么处置：从项目中移除后续都用新域名」＋「2、A 立项修」。

结果 = ⚠️ 只完成取证与方案，落地被全局执行锁挡住（锁占用者 = 另一会话「注册页人机验证+邮箱验证码」，09-19 06:45 起；本轮 原地有界等待约 20 分钟（4 次 sleep 后重试抢锁）仍未释放 ⇒ 按 R9 不接管、不删锁，收棒并把方案沉淀给接续棒。

本轮产出（⛔ 全部只读取证 + 1 份待执行方案，零共享资源改动）

方案落盘：_tmp_dompurge/PLAN-旧域移除与并集立项_20260919.md（分桶 A–F／S1–S7／验收／回滚／任务 2 根因链／本轮发现）。
旧域命中分桶（约 120 文件，全机 + 全仓）：
- A 运行时事实源：src/config.ts:312 与 src/net/relay/directory.ts:81 的内置种子 https://alotbuy.com/dshs-relay；🔴 真 bug = web/wake.html:92-94 白名单 /(^|\.)alotbuy\.com$/ ⇒ 切域后 next 参数被拒；lib/** 是 build 产物 ⛔ 不手改；test/overlay-bootstrap.test.mjs:188 断言须随改。
- B 服务器现行配置：47 overlay-443fb.conf:42/43（SEEDS 5 条含 2 条旧域＋ ADDR_OVERRIDES 旧域项）、106 /etc/dshs-worker.env:26（同 5 条）；106 dshs-relay-client.service:8 已是新域 ✅；47 /etc/dshs.env:3-5 已切 ✅。
- C 旧域 nginx 块（我自决 = 保留但降级，理由 = 彻底删会同时砍掉老流量入口/软回滚/已入网节点旧域候选 ⇒ 净变差触 R11）：alotbuy.com.conf（6098 B，旧域仍是独立可用门户）→ 降级为 301 跳板（仅留两个中继 location ＋ ACME）；relay-direct.conf（server_name relay-direct.alotbuy.com）与 dsh.alotbuy.com.conf（纯 301 装置）保留，退役条件 = 旧域 30 天流量为 0。⛔ CF 侧 DNS 不在我范围。
- D 现行文档/技能：含 🔴 技能 dsh-change-workflow 内「⚠️ 正确域名 = alotbuy.com」= 过期硬事实，须改（技能三处同步）。
- E 不改 = 历史归档（04-调整方案/** 含档案 22、交接单/archive/**、archive/**）—— 改了就是篡改历史。
- F 排除 = work.alotbuy.com（Gitea）与代码仓其余临时目录。

🔴 关键判据（写进方案供下一棒直接用）

A 类代码默认值运行时收益 = 0（生产 drop-in 已显式配 SEEDS）⇒ 其部署与任务 2 合并，只重启一次控制面，避免为洁癖单独中断。
B 类也须重启才生效（env 在进程启动时读）⇒ 所有运行时改动合并一次 restart dshs（47）＋ restart dshs-worker（106）。
curl -s --http1.1 -H "Host: ai1net.com" http://127.0.0.1/dshs-overlay/bootstrap 实测 relays[]/bootstrap[] 仍 5 条含 2 条旧域（Manager 从 SEEDS 派生）⇒ 改 SEEDS 即改目录，这是"移除"的落地机制。
任务 2 根因链（已取证）：lib/web/server.js:672 的 online 兜底（:694-705，读单一 DSHS_RELAY_STATUS_URL=47 中继）与 presence（:590-596 订阅，同样只连一台）⇒ rendezvous.js:32-47 取不到 ⇒ resolve() 返 undefined ⇒ reachability.js:62-71 按 P0-3 抛错。⚠️ 立项须先核「会合中继拆分」方案 §2 C3 避免重复设计；且修前必须补测"worker 漂回 106 自家中继时是否仍 500"（上棒只验了"落回 47 中继即恢复"）。

🔴 本轮发现 · 只报告未动手

106 dshs-relay-client 单元 = inactive（--client --url wss://ai1net.com/dshs-relay --host w-106 --ports 19000）；106 中继实测可用 ⇒ 疑为历史遗留单元。
BRIEF §2 集群拓扑「106 经 SSH 反向隧道」= 既有过期描述（隧道早已下线、现走自研中继），未顺手动。
47 vhost 目录遗留 _pending-ai1net/（我上轮 staging）待清。

接续棒：已登记一次性 automation 924be311-a14f-4aa8-8634-5f87ed3dc301（09-19 07:20 开跑，= 收口 + 8 分钟），prompt 指向上述方案文件并要求"锁被占则有界等待、不接管"。

边界自证：⛔ 未 commit / 未 push｜⛔ 未改任何共享资源（零 src/lib/web/test 改动、零服务器改动）｜⛔ 未接管、未删锁（R9）｜⛔ 令牌明文不入档｜✅ 唯一落盘 = 本机工作区 _tmp_dompurge/（非受锁路径）。

06:45–07:15 · 注册页 —— Cloudflare 人机验证＋邮箱验证码＋防爆破（档案 134 · 已上线验收）

用户指令（原话）：「注册账号页面增加，cloudfare人机验证和 amber发送邮件验证码的验证（增加重复获取验证码的爆破设计）」

交付：注册 = 用户名＋密码＋ 邮箱验证码（人机验证接口已就位但未启用，缺 Turnstile 密钥）。DB 迁移 v10（users.email ＋唯一索引 LOWER(email) ＋ email_codes 事件表 2 索引）。邮件走可插拔驱动（brevo 默认／通用 http／log）。新增 4 个模块：src/web/{register-guard,mail,turnstile,email-code}.ts。

防爆破（用户点名部分） —— 三层配额＋ 递增冷却阶梯（60→60→180→300→900→1800 s，档位 = 最近 1 小时已发起次数）＋试错 5 次即作废＋码只存哈希（sha256(email|purpose|code|encryptionSecret)）＋ 单次使用（CAS）＋与用户名绑定。三条顺序不变式：先人机验证再花配额｜被拒也落库（= 配额来源＋撞击证据）｜发信成功才记 sent。🔴 计数落 DB 不落进程内（一次 restart 即清零 = 等于关掉限流）。

线上实测（https://ai1net.com，全部真值）：发码 200 {ok,retryAfterSeconds:60} → 立刻重发 429 + retry-after: 58；事件表 sent ＋ throttled(email_cooldown)；审计 register_code_sent/_rejected 带真实客户端 IPv6；Brevo delivered ×2（959046/261788）；错码 400 {code_invalid,attemptsLeft:4}；正确码 201 建号成功、users.email 落库；同邮箱重放 409 email_taken。本机：新 17 条用例全通过｜全量 217 pass / 0 fail / 1 skipped｜layering 无新增违规｜verify-static 全合格｜其余 10 个 verify 全 OK。

部署：lib/**＋web/{register.html,i18n.js} → /opt/dshs/（只传本次改的文件，非整包）；备份 /opt/dsh/backups/register-verify-20260919_070418/；新 drop-in dshs.service.d/register-verify.conf（600，4 条 DSHS_MAIL_*）。回滚 = 把该 drop-in 改名＋ daemon-reload ＋ restart dshs。

踩坑（4 条，已写进档案 §事故）：① DSH 曾进用户可见邮件主题（brand 默认写成 'DSH'）⇒ 改为由 baseDomain 推导（→AI1NET），空则整句退化并加断言禁内部名；② 本机默认 node 是 24，better-sqlite3 按 22 编译 ⇒ ERR_DLOPEN_FAILED，跑测试必须用 Node 22；③ 冷却阶梯与小时配额互斥（emailPerHour=5 ⇒ 阶梯第 6 级永远不可达）⇒ 改 6 并加断言 ladder.length === emailPerHour；④ 新用户实例目录由容量分配落在 w-106（47 上看不到）⇒ 删测试账号必须两机都清（已加到 dsh-change-workflow R4 段）。

产物：档案 04-调整方案/134-注册页人机验证与邮箱验证码.md（已镜像 /opt/dsh/docs，对账一致）；INDEX §二已登记；收尾四件套全绿（docs-audit RC=0 无 P0）。

技能同步（跨载体扫描后改）：dsh-change-workflow/SKILL.md（服务器行 + R4 新增"两机都要清"）｜dsh-instance-diagnose/SKILL.md｜dsh-env-bootstrap（resident-rules.py ＋重生成快照，--check RC=0）。 🔴 根因：~/.ssh/config 别名 bt-server 的 Port 32022 已失效（sshd 只监听 22）⇒ ssh bt-server＝refused，且本仓 scripts/*.sh 默认走该别名 ⇒ 必须 [email protected] bash scripts/docs-sync-check.sh。⛔ 未改 ~/.ssh/config（用户环境文件，只报告）。

遗留 / 未闭环：🔴 Turnstile 未启用 —— 本机 CF 令牌（/etc/cloudflare-ai1net.ini）实测 zone 级（GET /accounts 空）⇒ 建不了 Turnstile widget，两把密钥只能你从 CF 控制台取；🟡 「amber」未对号（本仓/本机/两机均无此物；唯一命中是档案 129 的日志服务候选 yaop-labs/amber）⇒ 当前按 Brevo 落地，换供应商只改 env；🟡 发件人仍是个人 Gmail（建议在 Brevo 验证自有域名）；🟡 users.email 未进 admin 用户列表；🟡 未 commit/push（用户级规矩）；🟡 47 另有 5 个 09-15 的孤儿用户目录（未动）。

⚠️ 如实交代 · 锁：本棒 06:45 抢全局执行锁，07:15 才释放（release 后复核 = 空闲 ✅）。期间「域名迁移线」的会话在 07:0x–07:1x 因本锁被挡、原地等待约 20 分钟后收棒（其日志 §07 已记录，并把 924be311 接续棒排在 07:20）。下次做长任务要按「抢锁前先列收口步骤」估时，避免长时间独占。

08:0x–08:1x · 用户三条拍板落地（发件域名 + noreply 发件人）

用户原话：「1、说一下在哪里操作｜2、就用brevo 发邮件，amber是日志服务我说错了｜3、用B方案：[email protected]｜4、调整完成后在处理」

落地（全部完成）：

Brevo 建发信域名 ai1net.com ⇒ 需 4 条 DNS ⇒ CF（zone 级令牌）逐条创建成功：brevo1._domainkey／brevo2._domainkey（CNAME，DNS-only）、@ 的 brevo-code:2d01b491… TXT、@ 的 SPF v=spf1 include:spf.brevo.com ~all（⚠️ 域上原本无 SPF）；_dmarc 已有（p=quarantine）未动。
🔴 正确触发端点是 PUT /v3/senders/domains/{d}/authenticate —— …/validate 回 404 resource_not_found（踩过）。调用后 ⇒ authenticated:true / verified:true。
发件人 [email protected]（Brevo sender id=2，POST /v3/senders）｜drop-in 改 DSHS_MAIL_FROM（旧值备份 register-verify.conf.bak-noreply-20260919-080724）＋ restart dshs。
线上实测：发码 200 ⇒ Brevo 事件 delivered ＋ from= [email protected]（755473 is your AI1NET verification code）。测试事件行已清（email_codes = 0）。

「amber」已对号：用户自己澄清 = 日志服务（= 档案 129 的 yaop-labs/amber），与邮件无关 ⇒ 邮件按 Brevo 落地，驱动仍可插拔。

收口：档案 134 已更新（决策表 / 部署段含 5 条 DNS 表 / 待办改为"只等你"）；接续包 接续包_注册页验证_20260919.md（工作区根）。 🔴 未登记自动接续棒 —— 判据 = 用户级硬规矩「要用户拍板的，等拍了再新建接续会话」：下一棒入口全是边界外事项（需你给 Turnstile 密钥 / 需你授权提交）⇒ 按该规矩不建，等你拍了再建（钩子第 ⑤ 条的兜底路径：已在回复里告知"不需要你开新会话，口令 = …"）。

接续包指纹 —— 接续包_注册页验证_20260919.md 的 md5 = ec614b8201d7ddf3358006d175e2133d（本文件内不写自身 md5，避免自指；开工前重算并与本行比对，不符 = 口径已更新 ⇒ 停手报告）。收口终态：mail 发件人已切 [email protected]（实测 delivered）｜email_codes = 0 行、无测试用户残留｜门户 portal=200 / register=200｜全局锁 = 空闲 ✅（08:1x 已释放）｜CF 新增 4 条记录（2×DKIM CNAME DNS-only + brevo-code TXT + SPF TXT），未动任何既有记录。

08:19–08:3x · 「使用代理访问」→ 抓 CF 官方 Turnstile 指南，捞出并补齐两处校验缺口

用户指令：「使用代理访问」。实测结论：该站点本机直连也是 200（proxy=200 / direct=200 都通）—— 上一轮 WebFetch 返回空不是网络问题，是抓取工具本身的问题（⚠️ 别再把"WebFetch 空结果"当成"站点不可达"）。改用 curl 经代理落盘：developers.cloudflare.com/turnstile/spin/prompt.md（31647 B / 419 行）。

🔴 对照官方 canonical siteverify 捞出的真实缺口（本次最有价值的产出）：官方要求三项齐备 —— success === true ∧ action 匹配 ∧ hostname 在白名单；我原先只校了 success。

为什么不校 hostname 是真漏洞：sitekey 是公开的（就写在注册页 HTML 里）⇒ 攻击者能在自己站点用我们的 sitekey 渲染 widget、为真人访客拿到合法 token，再拿去打我们的注册接口。只校 success 时这条路完全通畅；hostname 由 CF 服务端判定并回显、访客篡改不了 ⇒ 它才是"这枚 token 只给我站点签发"的唯一证据。
通用教训（已写进技能）：凡「公开 key + 服务端校验」的模型，都要追问"这枚 token 凭什么只给我用" —— 答案通常是 hostname / audience / origin 这类服务端回显的绑定字段。

改动（5 处）：web/turnstile.ts（补 action/hostname 校验 + token 2048 上限 + verifyUrl 可覆盖以支持逐组合单测）｜config.ts（新增 DSHS_TURNSTILE_ACTION 默认 signup ＋ DSHS_TURNSTILE_HOSTNAMES；新增 normalizeHostnames()／resolveTurnstileHostnames()，导出了便于单测）｜email-code.ts（captchaPartiallyConfigured()；turnstileEnabled 要求白名单非空）｜routes/auth.ts（配置端点下发 action；"密钥给了但白名单空"⇒ 进程内首条 WARN，防"看起来配了、实际没防住"）｜web/register.html（render 传 action，取值由服务端下发防漂移）。

零回归三证：新单测 19/19（含 Turnstile 五组合 + 本地拒空/超长 token 不打上游）｜全量 219 pass / 0 fail / 1 skipped（# tests 220）｜check-layering 无新增违规＋ verify-static 全合格。 配置解析实测 5 形态：派生 → [ai1net.com,www.ai1net.com]｜显式含旧域 → 4 条 ✓｜URL 形态误填 https://AI1net.com:443/x → 归一成 ai1net.com ✓｜显式空 → []（= 关闭）✓｜action 非法 → 回落 signup ✓。 部署验收：13 文件 → 47（备份 $B/pre3-turnstile.tar）＋ restart dshs；md5 五项两端一致；配置端点出现 "action":"signup"、register.html 含 cfg.captcha.action、门户 200、发码仍 200 ⇒ 补强零回归（未配密钥 ⇒ 行为与补强前一致）。测试残留清零（email_codes=0；47 users/ 目录 7 = 2 真实 + 5 历史孤儿，本轮未新增）。

⚠️ 一个必须记住的坑：主机名白名单必须含旧域 alotbuy.com —— 旧域门户仍在线（软回滚路径）⇒ 只写 ai1net.com 会让人机验证把从旧域注册的访客拒掉。

技能同步：dsh-change-workflow 的「第 6 条一次性 token 类」扩写（三项校验 + 通用追问 + 配套四条 + 官方指南 URL）；档案 134 新增 §实现 D 与踩坑第 0 条（置顶）。

「在哪里操作」最终答案（两条路，已写进档案 §待办 1）：路 A = CF 控制台 → 左侧 Turnstile → Add widget（hostname 填 ai1net.com 等、Mode = Managed）→ 取 Site Key + Secret Key 发我；路 B = 你给一个含 Account → Turnstile → Edit 的 account 级 API 令牌，我用官方 API 自建 widget 并把密钥直接写进服务器 drop-in（不进聊天），你零操作（该令牌权限更大，用完请撤销）。

08:4x · 用户给密钥 ⇒ Turnstile 正式启用＋登录/注册页品牌标识改造（档案 137）

一、Turnstile 启用（写入档案 134 §实现 E）

用户按「路 A」在 CF 控制台建好 widget 并提供两把密钥 ⇒ 写进 600 的 drop-in（SITE_KEY / SECRET / ACTION=signup / HOSTNAMES 四样）＋ restart dshs。

密钥自证：假 token 打 siteverify ⇒ 回 invalid-input-response（而非 invalid-input-secret）= 私钥被 CF 认可。
线上验收：配置端点 captcha.enabled=true + siteKey + action:"signup"｜无 token ⇒ 403｜假 token ⇒ 403。
⛔ 私钥不入任何文档/记忆，只落 drop-in（600）；备份 register-verify.conf.bak-turnstile-20260919-083853。
⚠️ 唯一未做 = 真人通过后的端到端（需真浏览器取真 token）⇒ 留给用户首次真实注册时自然验证。
HOSTNAMES 写 4 条是超集（含旧域）——CF 的 widget 域名列表才是第一道闸门，超集只是防止旧域访客被误拒（旧域退役后可收窄；档案 135 已把它降级为 301）。

二、品牌标识改造（新档案 137）

用户原话：「登录和注册页面上的 deepseek的图标去掉，改为中文：能力枢纽小写 CapabilityNet ，英语和其他语言：CapabilityNet」

改动：login.html / register.html 的 .auth-brand 去掉 DeepSeek 鲸鱼 <img>（logo.svg）＋内联「DeepSeek」文字 SVG（131×24） ⇒ 换成 <span class="wordmark" data-i18n="brand.name">CapabilityNet</span>；i18n.js 加词条（en=CapabilityNet / zh=能力枢纽）；design.css 的 .auth-brand .wordmark 由「定高 22px（给 svg）」改为文字排版（19px/600/行高1.2）。
为什么不写死在 HTML：① verify-static.mjs 的 I18N_PAGES 已把这两页列入"不得有裸中文"；② 「英语和其他语言」要的正是回退 —— 只写 en 一条即覆盖所有其他语言（i18n 缺 key 回退 en）。
新增回归测试 test/i18n-brand.test.mjs：用 node:vm ＋最小 DOM 桩跑仓库里那份真实 i18n.js，断言六条语言路径的实际渲染结果（浏览器 en/zh、?lang= 双向覆盖、cookie、未支持语言回退）。⇒ 品牌文案漏配是静默失败（中文用户看到英文），必须钉。
实测：六条全绿｜grep -ic deepseek 两页 = 0/0｜静态校验全合格｜全量 221 pass / 0 fail / 1 skipped（# tests 222）｜线上 4 文件 md5 两端一致｜回滚点 /opt/dsh/backups/rebrand-20260919-084220/pre.tar。
未做（只报告）：🔴 favicon 仍是 DeepSeek 鲸鱼（logo.svg 兼作 favicon，换它需要一份新图标资产）｜🟡 admin.html / portal.html 顶栏 wordmark 仍是 DeepSeek 图形（用户只点名登录/注册页）｜🟡 死资产 web/deepseek-text.svg / web/deepseek.webp 全仓无引用。
待澄清：「小写 CapabilityNet」两种读法 —— 本轮按「中文=能力枢纽／其他=CapabilityNet」实现；若是「中文页再加一行小号 CapabilityNet」或「全小写 capabilitynet」，改动量 = i18n.js 一处＋ design.css 一行（不碰 HTML）。

三、两条环境事实（本次取证顺手拿到，都是"会被误判"的那类）

🔴 本仓 core.autocrlf=true，而 HEAD 里前端/源码文件全是纯 LF ⇒ 工作区 CR 数不能用来判断"我是否改了行尾"（git status/diff 会被规范化，看不出差异）。判"有没有引入行尾偏差"必须与部署目标比：本次实测服务器 /opt/dshs/web/ 为 design.css=CRLF、login/register/i18n=LF、admin/portal/index=CRLF，与我本地 4 个待传文件逐一对应 ⇒ 无偏差。 ⚠️ 差点误判成"Edit 工具把 design.css 转成了 CRLF"（我本地 CR=272 vs HEAD CR=0）——根因是 autocrlf，不是编辑工具。
⚠️ node:vm 上下文只含 ECMAScript 内置、不含 Web API ⇒ 在里面跑 web/i18n.js 必须先注入 URLSearchParams / URL，否则 new URLSearchParams(location.search) 抛错被 i18n 的 try/catch 吞掉，表现为"?lang= 不生效"的假失败（本次第一版踩到，2 条用例假红）。

09:0x · 用户「一并替换」+「会话页面先不替换」⇒ 品牌标识改造收官（档案 137 改名扩容）

用户三句：「一并替换」｜（我上轮列的 4 个待定项）｜「会话页面左上角的 deepseek 先不替换」

🔴 边界判定（本棒最有价值的一条）

先取证「会话页面」是谁：web/index.html 是纯跳转页（无 UI、无 deepseek）⇒ 会话页面 = 用户实例内的 dsh 会话窗口，其左上角标识由官方 @deepseek-ai/dsh 的 client bundle 渲染 ⇒ ① 不在本仓 web/ 目录；② 受 R2（不改官方 dsh 主程序） 约束，只能走 profile 层官方插件机制。⇒ 用户说"先不替换"与技术边界完全一致，已写进档案 §0 作为范围声明。

本次实际替换（四页＋ favicon）

对象	处置
`admin.html`	`.auth-brand` 与 login/register 同构 ⇒ 删图标＋删内联 DeepSeek SVG ⇒ `<span class="wordmark">能力枢纽</span>`（该页纯中文未接 i18n ⇒ 直接写中文）。11913 → 7928 B
`portal.html`	顶栏只换图标 `logo.svg` → `favicon.svg`；⭐ 「管理门户」保留（那是页面定位名、不是 DeepSeek 痕迹，删它属越界）
`web/favicon.svg`	新建（1008 B）：hub 意象（圆角深底 + 中心节点 + 3 辐条 + 3 外环），配色取平台 token（`#0f1c33` / `#38d6d0`），刻意避开 DeepSeek 蓝 `#4D6BFE`
四页 head	`href="/logo.svg"` → `/favicon.svg`（新文件名天然绕过浏览器 favicon URL 缓存，⛔ 不需 `?v=`）

🔴 本棒踩到的真坑：SVG 的 XML 注释不能含 ASCII 双连字符 `--`

favicon 第一版注释里写了 CSS 变量名 --ink / --accent-2 ⇒ XML 语法不允许 ⇒ 整份 SVG 解析失败 = 图标静默不显示（页面与接口都不报错）。抓到方式 = 用真解析器验（ET.parse 报 not well-formed (invalid token): line 5, column 24），肉眼与"标签配对检查"都看不出。 ⚠️ 判据澄清：中文破折号 ——（U+2014×2）合法，只有 ASCII --（U+002D×2） 非法。 ⇒ 已固化为判据：scripts/verify-static.mjs 新增 SVG 段（开头/结尾/viewBox/去痕迹/注释双连字符）＋ 反向自证（注入坏样本 ⇒ 必须报红 ⇒ 清理复绿）。技能 dsh-change-workflow 的第 4 条同步记录。

零回归

verify-static 全合格（6 页 + 7 内联脚本 + 3 css/js + 3 svg）｜全量 221 pass / 0 fail / 1 skipped｜残留检查：四页线上 grep -ci deepseek = 0/0/0/0；本地仅 design.css/i18n.js 各 1 处注释内命中（改动说明，必要留痕）｜favicon.svg 线上 200 + image/svg+xml｜5 文件 md5 两端一致｜行尾逐字节核对与该目录既有风格一一对应（admin/portal=CRLF、login/register/favicon=LF）。回滚点 /opt/dsh/backups/rebrand2-20260919-090205/pre.tar（600）。纯静态资源 ⇒ tar 覆盖即生效，无需重启。

档案改名：137-登录注册页品牌标识改造.md → 137-品牌标识改造-去DeepSeek图形.md（内容已扩到管理页，名实须符）；INDEX 描述同步重写；服务器镜像删旧名、传新名（md5 188d33d7… 两端一致）；134 里的交叉引用一并更新；四件套复跑（无悬空引用 / 无 P0）。

未做（只报告）：🟡 index.html / wake.html 本来就没有 favicon link（标签图标是浏览器默认；未加，属功能增量）｜🟡 三个 DeepSeek 资产 logo.svg / deepseek-text.svg / deepseek.webp 现已全部零引用，未删（不可逆动作需用户点头，git 可恢复）｜⚪ .topbar .wordmark 那条 CSS 保留（当前无页面使用）。

09:1x · 「提交到仓库」—— 三条线合并入库＋双推（`971ccc3`）

用户指令：「提交到仓库」

提交：971ccc3（父 d2ef362）· 56 文件 · +3498 −193 · 分支 master。 message 分列三条线（档案 134 注册页人机验证+邮箱验证码／档案 137 品牌标识去 DeepSeek ／档案 135·136 域名迁移线），并如实标注"域名迁移线为另一会话产出、本会话只入库未复验"。

为什么合成一个 commit（而不是按线拆两个）： ① 两条线的改动都已完成并上线（源码与生产此前不一致 = 隐患）； ② 交叉文件无法干净拆（src/config.ts 两条线都改、INDEX.md/docs-manifest.json/skills/* 同理），强拆需 git add -p 且易拆出"单独 checkout 不自洽"的中间态； ③ 仓库既有惯例就是混批（上一条 d2ef362 也是 20 文件混批 + "附序㊽补提交"）。

暂存方式（⛔ 未用 git add -A）：git add -u（全部已跟踪修改）＋ 显式列名 add 未跟踪文件 ⇒ 三个历史临时目录 _tmp_seq24/、_tmp_seq40/、_中间产物_待清理/ 明确排除（提交后 git status 恰剩这 3 项）。

🔒 提交前敏感信息双证（这次特意做了）： ① 49 个待提交文件按 7 类模式扫（CF 令牌 / Brevo key / Turnstile / 宝塔 / GitHub PAT / 私钥头 / 密码字面量）⇒ 零命中； ② 用精确值全仓再扫一遍（secret 与 Brevo key 各 0 处；sitekey 仅 1 处 = 档案 134，公钥本就公开在页面 HTML 里，允许入档）。 ⇒ 结论：私钥与邮件密钥均未入仓，与"密钥只落 600 drop-in"的口径一致。

双推结果：原仓 work.alotbuy.com ⇒ ✅ d2ef362..971ccc3；CNB ⇒ ✅ d2ef362..971ccc3。 三方对账（用 ls-remote 取裸 sha，⛔ 不信本地缓存）：本地 = 原仓 = CNB = 971ccc3703a4396bfb366b75c8471bc1dd510795；git remote -v 确认两条 pushurl 未被挤掉。

🔴 提交后浮出的遗留（已提交、但服务器文档镜像落后）：docs-sync-check.sh（须 [email protected]）显示 —— 内容不一致 9：02-运维手册.md、BRIEF.md、README.md、DEPLOY-本部署.md、交接单/README.md、ops/nginx/alotbuy.com.conf、scripts/{stop-dialog-guard.py,docs-consistency.py,cf-probe.py}（均本地新、服务器旧，属域名迁移线只同步了一部分）｜仅本地 38（19 份档案＋ 13 份归档交接单＋ ops 等）｜仅服务器 5（一个 .bak-seq17-* 备份目录）。 ⇒ 未擅自同步（47 文件 > 10，触「禁未经确认的批量操作」）⇒ 只报告；影响面 = 实例内看到的 /opt/dsh/docs 是旧版。同步命令 = cd dsh-server-docs && [email protected] bash scripts/docs-sync-check.sh（看清单）→ 按清单 tar 推送。

边界自证：⛔ 未 git add -A｜⛔ 未动三个历史临时目录｜⛔ 未删任何文件｜⛔ 未同步文档镜像（超批量阈值，只报告）｜✅ 提交前查过 git config user.*（代码仓已有 maogeigei / [email protected]）｜✅ 全局执行锁按要求在收尾释放。

09:18 · 用户三条拍板收尾：文档镜像同步（47 文件）＋图标定稿＋资产保留

用户原话：「1、A 现在同步（47 文件）｜2、A 就用这个｜3、B 留着不提交」

① 文档镜像同步（已完成）：按 docs-sync-check 差异清单精确推送 47 个（38 仅本地 + 9 内容不一致），tar -T <清单> 打包（1.4 MB）→ scp → 服务器侧先 tar -cf $B/pre.tar -T <同一清单> 留回滚点（/opt/dsh/backups/docs-sync-20260919-091840/，600）→ 解包。 复跑对账：一致 238 / 内容不一致 0 / 仅本地 0；剩余「仅服务器 5」= 历史备份目录 .bak-seq17-*（无害，未删）。 ⇒ ⚠️ 该 47 文件批量操作已获用户当轮明确批准（此前我按 R7 只报告未动，用户本轮选 A）。 🔑 口径沉淀：回滚依据 = 本机 git 仓库（文档库已全量提交在 971ccc3）⇒ 服务器侧无需整目录备份，只按清单备份被覆盖的那批即可。

② 图标定稿：新 web/favicon.svg（hub 意象）用户确认采用，无需返工。

③ 三个 DeepSeek 资产：web/logo.svg / deepseek-text.svg / deepseek.webp（均已零引用）→ 保留不删（用户选 B；不提交、不动）。

本会话累计产出（三条线，全部已上线 + 已入仓 971ccc3 + 已双推）：

档案 134 注册页人机验证 + 邮箱验证码（含防爆破；Turnstile 三项校验；Brevo + [email protected]）
档案 137 品牌标识改造（四页 + favicon 去 DeepSeek；新增 test/i18n-brand.test.mjs；verify-static 加 SVG 段）
档案 135/136 域名迁移线（另一会话产出，本会话只入库未复验）

09:2x · 强制收口（上下文超 30 万 + 80 次工具调用）

接续包指纹 —— 接续包_注册页验证_20260919.md 的 md5 = def6b05446781ffd6849d6f484623aa7 （⚠️ 已重写过一版：内容扩充为「收官后」状态；该指纹即当前有效口径）。 自动接续已登记：automation 4b211be9-058d-4f7c-a8ab-77dec9cfa415（一次性 · 2026-09-19 09:22 触发 · 会话名「接续-注册页验证与品牌标识-收官」）。 prompt 已按规范：开跑即 state.py → 校验接续包 md5（不符即停）→ 开机四步 → 第③条明确写「本任务无待执行项，核实完成状态后直接报告结束，⛔ 勿自行开工」 → 工具调用上限 15 → 抢不到锁只报告。

🔑 一条编排经验（本次刻意做的取舍）：钩子要求"登记接续棒"，但本任务已无待执行项 ⇒ 若按常规写"继续推进"，下一棒会空跑产生无谓成本。正解 = 照常登记（满足"用户可感知的变更必须显式告知"与自动接续通道的要求），但在 prompt 第③条把默认动作定为「核实完成状态 → 报告 → 结束」，并给出抽查项（镜像对账 / 线上端点 / HEAD sha）与"状态被破坏时"的处置路径。 ⇒ 通用化：收口棒登记时，必须在 prompt 里写清「本轮应做什么 / 若无事该怎样结束」，否则下一棒要么空转、要么自行发明任务。

本会话收口自证：全局执行锁 = 空闲 ✅｜工作区只剩 3 个历史临时目录（未动）｜临时脚本已清（/tmp 下 sync*.txt 与 wb-scratch 内脚本）｜⛔ 未开新任务。

07:2x–08:1x 序㊿执行棒 —— 旧域 `alotbuy.com` 移除（任务 1 交付）＋控制面并集立项（任务 2）

产出：落地档案 04-调整方案/135-旧域alotbuy.com从项目移除.md（新建）｜立项交接单 04-调整方案/136-控制面按两台中继取并集-立项交接单.md（新建）｜INDEX.md 登记 04-135/04-136（字节级插入，CR 计数 5 保持）｜BRIEF.md §入口 回填（301 过渡＋候选链 5→3 ＋修正 RUNBOOK 路径 pending/ 已不存在）。

任务 1 三处落点：① 代码 src/** web/** test/** scripts/**（10 源文件＋ 2 测试＋ 2 live 校验＋演练脚本＋探针注释）＋ lib/ 重建后 scp 15 个产物（md5 全对）；② 服务端 —— 47 drop-in overlay-443fb.conf SEEDS 5→3、106 /etc/dshs-worker.env（备份 .bak-dompurge-20260919-073149）、旧域 nginx 站降级为 301 过渡装置（map $host 子域映射；仅留 ACME ＋ /dshs-relay ＋ /dshs-overlay/bootstrap）；③ 文档技能 —— 文档库 42 处精确替换＋本机 .workbuddy/skills/ 6 份清理＋ 47 镜像 6 份 scp。

三条实测教训（写进 135）：① 候选链改完不生效 ⇒ Manager 把自己发布的签名目录缓存在 /var/lib/dshs/overlay/directory.json（可再生）且懒重建 ⇒ 必须"删缓存＋二次重启控制面"才生效（一次重启后仍是 5 条）。② 演练"假红"：域迁移后 --scene all 报 11P/1F，红在幕4-A「目标不是 47 那台」—— 实为脚本用硬编码域名字符串匹配端点（豁免真生效）⇒ 两处匹配器改读参数表 DRILL_KILLED_MATCH；凡域迁移类改动必须同步这个键。③ 脚本行号表必漂移 ⇒ 先自己 scoped grep、再字节级替换（计划写 config.ts:312，实为 :381）。

验收终值：探针 29 PASS / 0 FAIL / 0 SKIP（rc=0；OBS-21 两机 count=3 hosts=3；零 alotbuy）｜演练 --scene all 12 PASS / 0 SKIP / 0 FAIL（rc=0，末行原文在案）｜门户 200 ｜旧域 301（含子域映射）｜relay 透传双域一致（裸 GET 404 / WS 101，双域同）｜探针三处同源 md5 55568f87bfe2dc8e43289c69b4126004｜参数表 §10 指纹 → 075a97239c2d1d8a1f442ec6cc787ede（2 键值格＋示例＋说明）。

遗留 / 未闭环：🔴 控制面并集仍未落地（= 上一棒 ⑤ 那条：Manager 对 via=relay host 只读单一 DSHS_RELAY_STATUS_URL；序㊾修了观测面、控制面未修）⇒ 已立项为档案 136，⛔ 本棒未排下一棒。🔴 D8 云安全组（唯一在册红，待控制台落地）未动。⚠️ 技能副本既存漂移：change-workflow（本机 1055 行 vs 文档库 1039）/ opensource-release（本机 1.8.2 vs 1.7.8）/ instance-diagnose（本机 SSH 别名更正更新）⇒ 本棒只做域替换、未覆盖（防丢内容）。⚠️ /opt/dsh/docs 镜像有 30+ 个"仅本地待推送"（本会话之前就存在）⇒ 只推了 6 个技能文件。⛔ 未 commit / 未 push（按用户级规矩）。

锁：07:20 抢到（旧域移除-控制面并集-20260919），08:1x 收口即释放。

09:0x–09:1x · 用户贴入 Google AI Mode 分享内容 ⇒「区块链 L2 / 私有链存用户敏感数据」技术审校（非本仓任务 · 零代码改动）

用户输入：先是裸链接 https://share.google/aimode/zuLzOtrzGdu5TM8xV，随后把全文原样粘贴（4 轮问答：L2 现状 / L2 能否存 RPG 与用户数据 / 公链存密码卡号是否安全 / 自建私有链是否可行）。

🔴 两条环境事实（本次取证拿到，都会造成误判）

share.google/aimode/* 分享链接自动化抓不到（curl / WebFetch / r.jina.ai / 真浏览器四条路全试过）：链接 302 → www.google.com/search?udm=50&… + 一次性 smstk/shmd 令牌 ⇒ 内容由前端 JS 现拉，落盘 HTML 里 区块链 出现 0 次、无 AF_initDataCallback；真浏览器则被 CF/Google 反爬验证页 sorry/index 拦下。⇒ 此类链接只能让用户直接粘贴原文，⛔ 别再花工具预算去"抓"。
🔴 本机沙箱内出网必失败：沙箱注入的 HTTPS_PROXY=127.0.0.1:63854 是沙箱内代理，对 Google 返回 502 CONNECT tunnel failed ⇒ 凡需真实外网一律 dangerouslyDisableSandbox + 显式 HTTPS_PROXY=http://127.0.0.1:10800（用户自己的代理，~/.ssh 无关；git config --global http.proxy 也正是 10800）。⚠️ 沙箱内 curl https://www.google.com 返回 000，不代表网络不通。・配套：agent-browser 本机原本未装（插件只下过 Chrome 到 ~/.agent-browser/browsers/）⇒ 已 npm install -g agent-browser（托管 Node 22.22.2-3，v0.27.0）；open 首次冷启要 30–45 s，前台直跑会撞超时 ⇒ 后台跑 + sleep 后读文件；收尾 agent-browser close --all。

审校结论（用户交付物 = 回复正文，无落盘文件）：Google AI 的大方向站得住（L2 = Rollup 主导 / 公链绝不能存密码卡号 / 私有链"防外不防内" / 遗忘权与不可篡改冲突 / 哈希锚定 + Tokenization），但有 5 处硬伤： ① 漏 EIP-4844 blob（Dencun 2024-03） = 改变 L2 经济学的最关键升级（数据成本降 90%+，L2 现处理以太坊 60–70% 交易量）； ② "2,000+ TPS 实际最高"混淆峰值与常态 —— 实测常态 Base ≈ 89、Arbitrum ≈ 57 TPS，2,000+ 只在 memecoin 尖峰出现； ③ ZK 的优势说反了 —— 是终局性（分钟级 vs 乐观汇总 7 天挑战期）＋无需诚实少数假设，不是"验证速度"（证明生成反而更重）； ④ "私有链一律无行级权限/全节点可读"过度概括 —— Fabric 的 channel / private data collection、Corda 的 need-to-know 分发本就有可见性隔离； ⑤ 事实错误：The Beacon 在 Arbitrum（后支持 Ronin）与 Treasure，⛔ 不是"Arbitrum Nova 承载"（Nova 是 DAC 型 AnyTrust 链，用途是低成本游戏/社交，没错，但举错例）；另 "Sequregator" 拼写错（= Sequencer）；口令哈希漏 Argon2id（OWASP 首选）。

另有 3 条 Google AI 没提、但对用户决策更重要的：① "防篡改 + 多方对账"≠ 必须上链 —— 签名 Merkle 日志（RFC 6962 / Trillian 式）或定期把 Merkle root 锚定到公链 OP_RETURN，成本 ≈ 0、运维负担远低于自建链；② 中国侧合规：运营区块链信息服务需网信办备案（《区块链信息服务管理规定》2019），且 PIPL 第 47 条删除权与链上不可删直接冲突；③ 自建链的真实代价在节点运维 / 共识 / 密钥 / 升级，小团队等于给自己加一条运维线。

边界自证：⛔ 未 commit / push｜⛔ 零本仓文件改动｜⛔ 未动任何共享资源｜✅ 收尾清理 = 删 _tmp_fetch/（15 个抓取中间产物）＋ agent-browser close --all（无活动会话，无残留进程）。

沉淀（用户指令：「把 google gemini 这套反扒技术也沉淀为文档」）：新建用户级技能 E:\ProgramData\.workbuddy\skills\web-fetch-antibot\SKILL.md（v1.0.0 · 2026-09-19 · agent_created: true）。内容 = 三层判据（A 壳页 / B 无头验证页 / C 正文代理回验证页）＋ 硬止损规则「同一 URL 换 2 种方式失败即停手、改向用户索取原文」（由来 = 本次 6 条路 × 十余次调用全部为空）＋本机沙箱代理陷阱（63854 vs 用户自己的 10800）＋ Google AI Mode 四道反爬链路全文＋六条路线结果账本＋「抓不到也要说清为什么」的交付姿势。・归属说明：该技能属跨项目通用，故只落用户级技能目录，⛔ 不进 DSH 文档库 skills/、⛔ 不进 /opt/dsh/docs/skills/ 镜像（那条「技能三处同步」规矩只对 DSH 平台技能成立）。・顺手记下的一条：q= 参数原文暴露提问内容（本次解出「区块链二级链技术发展的如何了」）⇒ 拿到此类分享链接第一动作 = 先解码 q=，至少能知道用户在问什么。

09:1x · 新线（非 DSH 线）· 去中心化数据链路 —— 调研确认 + 方案文档已沉淀

用户指令（原话）：「结合你的判断在调研确认一次，沉淀一份后续做去中心化数据链路的方案文档」

交付物：去中心化数据链路方案_20260919/去中心化数据链路-技术方案与落地路线_20260919.md 指纹 = 334 行 / 22106 B / CR=0（纯 LF）/ md5 e7847f025c1f18ef93d644aacd129abc。

⚠️ 落点判定（本棒第一个自决）：该线不属于 DSH 平台（工作区根 BRIEF.md 对「区块链/去中心化」零命中；DSH 文档库有 INDEX/manifest/四件套，塞进去要占 04 号且污染索引）⇒ 落在工作区根新建独立目录，⛔ 不进 dsh-server-docs/04-调整方案/、⛔ 不进 /opt/dsh/docs 镜像。

文档骨架（10 节）：§0 结论先行（三行判定 + 一条反判定）｜§1 前提 P1–P4｜§2 第一决策：到底需不需要链（5 行目标表 + "谁和谁不信任"判据）｜§3 数据分层落点表 + 四条「加密上链 ≠ 安全」理由｜§4 三档路线（A 透明日志+锚定／B 联盟链／C 公链 L2）｜§5 敏感数据专项（含 ZK 能与不能）｜§6 合规（含 §6.1 适用性判据）｜§7 落地 S0–S4｜§8 判据汇总 7 条｜§9 负面清单｜§10 来源与勘误表。

本轮调研新拿到的三条关键事实（此前判断里没有）

🔴 合规适用性判据 = 《区块链信息服务管理规定》第二条：「通过互联网站、应用程序等形式，向社会公众提供信息服务」⇒ 纯内部、不对公众开放 ⇒ 一般不落入适用范围。这是决定合规成本的第一道闸门，此前只当作"要备案"一刀切。⚠️ 但"对内系统 + 对外留了查询/展示入口"属边界模糊地带，文档已写明须取得书面确认、⛔ 不自行推定。
🔴 备案是持续义务不是一次性动作（第 14 条定期查验），且制度仍在运行（网信办已发至第二十四批境内备案编号，最新批 2026-07-21，38 个）。义务清单其余：第 11 条 10 工作日备案／第 8 条实名认证（未认证不得服务）／第 9 条上线前安全评估／第 13 条显著位置标编号／记录留存**≥6 个月**／罚则 1–3 万。
联盟链选型分水岭 = 国密 + 部署成本：FISCO BCOS（国密 SM2/SM3/SM4 原生、共识 PBFT 秒级、单链 1,000–3,000 TPS、单机 4 节点一条命令可起）vs Fabric（通道/私有数据集隔离更强、5,000+ TPS、部署复杂、国密需自行配置）⇒ 国内合规场景首选 FISCO BCOS。自研链代价锚点 = 20 人以上底层团队 / 年成本 500 万级 / 用成熟框架可省约 60% 人力。

文档里最有价值的一条自研结论（非搜索所得，是判断）："防内部篡改"只需「检测」不需「阻止」 ⇒ 单写入方场景不必上链，Merkle 只追加日志（RFC 6962 式，含包含证明 + 一致性证明）+ 公链锚定即可，成本低一个数量级；且配套必须要有"真的会去验证的人"（第 7 条判据：没有任何人验证的透明日志 = 没有）⇒ 用 §2 的「谁和谁不信任」一句判据定档，避免越级选型。

边界自证：⛔ 未 commit / push｜⛔ 零本仓既有文件改动（只新建一个独立目录）｜⛔ 未动服务器 / 未动共享资源｜⛔ 未改任何技能（新沉淀的 web-fetch-antibot 属上一棒）｜✅ 全程只读调研 + 一次落盘。

09:2x · 同线细化 · 形态确认为「面向公众资产平台＋隐私金库」⇒ 第二份落地文档

用户拍板（原话）：「还是面向公众的资产平台和保存用户隐私的信息的加密级数据保存仓库」

交付物：去中心化数据链路方案_20260919/面向公众资产平台与隐私金库-落地方案_20260919.md 指纹 = 293 行 / 19477 B / CR=0（纯 LF）/ md5 8c5c218d5ff54862a63a6e085e44476e （主文档指纹不变 = 334 行 / 22106 B / e7847f025c1f18ef93d644aacd129abc）

🔴 本轮最有价值的发现 —— 本项目的第一道闸门不是技术，是法律

补查 银发〔2021〕237 号《关于进一步防范和处置虚拟货币交易炒作风险的通知》（央行等十部门，2021-09-15），拿到条文级原文：

🔴 「虚拟货币相关业务活动属于非法金融活动」，一律严格禁止、坚决依法取缔；列举范围 = 法币兑换／币币兑换／中央对手方买卖／为交易提供信息中介和定价服务／代币发行融资／衍生品；境外交易所向境内居民提供服务同样非法；
🔴 连带责任条款（最易被忽视、杀伤力最大）：追究「明知或应知其从事虚拟货币相关业务，仍为其提供营销宣传、支付结算、技术支持等服务的法人／非法人组织／自然人」⇒ 「我只做技术、不碰资金」不构成免责；
🔴 配套硬约束：互联网企业不得提供网络经营场所／商业展示／营销宣传／付费导流｜企业注册名称与经营范围不得含「虚拟货币／虚拟资产／加密货币／加密资产」字样｜金融机构与支付机构不得提供账户开立／资金划转／清算结算 ⇒ 合规支付通道直接不可得，商业模式是否成立受影响。

因此本方案 §0 判定一 = 合规边界先于技术方案；文档把可行形态收敛为两个（数字藏品一级发售 依《关于防范 NFT 相关金融风险的倡议》2022-04 三协会／公众可核验存证平台），并把「可交易/可兑换/可分割/带金融属性」明确列为不可做。

架构结论（自研判断，非搜索所得）：两个需求必须做成两套互不信任的子系统＋一条窄桥——

A 层（可公开）：联盟链 FISCO BCOS / 透明日志；永不出现明文个人信息；
B 层（永不公开）：加密关系库＋ KMS/HSM；永不参与共识；
桥 = 匿名 ID 映射表（HMAC(服务端密钥, userId)，⛔ 不用裸哈希 —— 手机号空间小、可枚举反推）⇒ 标注为最高价值攻击目标，须独立加密／独立审计／双人授权／每次留痕，并做关联性测试。
🔴 公链 L2（Base/Arbitrum）在本场景明确不适用（面向公众发行资产落 §1.1）。

隐私金库三档（判据 = 平台是否需要读到明文）：V1 中心化加密库＋KMS（基线）→ V2 阈值解密 N-of-M（推荐升级）→ V3 客户端加密＋IPFS/Arweave（最强，平台零知识）。V3 三条硬代价已写明：丢钥＝永久丢失／服务端无法检索统计／🔴 可能无法履行司法配合义务（境内平台有配合调查义务，平台自己解不开怎么办 ⇒ 须先取法律意见，不得自行推定）。

同一条被判死的错路：「加密后上链」 ≡ 不满足删除权＋密钥轮换不可行 ⇒ 形成「历史数据永远更弱」的斜坡（PIPL 47 条 vs 不可篡改，四条理由见文档 §5.4）。

边界自证：⛔ 未 commit / push｜⛔ 零既有文件改动（只新建第 2 份文档）｜⛔ 未动服务器 / 共享资源｜✅ 调研 1 次搜索 + 落盘 1 次。

09:3x · 同线第三份 · 范围澄清（237 条不适用）＋架构落地＋隐私保密最优解

用户三句（原话）：「① 这些都不涉及只用区块链去中心化技术储存和查询数据」｜「② 架构上…按照你的判断规划」｜「③ 如何确保用户隐私数据保密 有没有更好的办法」

交付物：去中心化数据存储与查询-架构设计与隐私保护方案_20260919.md 指纹 = 390 行 / 27070 B / CR=0（纯 LF）/ md5 01c4500b49da0e709a1b9ff36421ae68 连带：文档 2 顶部加状态声明（§1 作废、§2+ 被取代、仅存档），新指纹 = 297 行 / 20257 B / 123bb0fc453f774a8a3c09f8b78733cf（⛔ 原 md5 已变，旧值 8c5c218d… 不再有效）。文档 1 未动（e7847f025c1f18ef93d644aacd129abc）。

一、范围重定（用户澄清 ⇒ 我现在接受该口径）

「只用去中心化技术做存储与查询」⇒ 无发行/兑换/撮合/定价/衍生品 ⇒ 不落入银发〔2021〕237 号规制范围；文档 2 的连带责任／经营范围禁用字样／支付通道不可得全部撤销。 ⚠️ 但唯一一项仍成立且与 237 无关：《区块链信息服务管理规定》第 2 条 —— 面向公众提供信息服务 ⇒ 仍需备案（10 工作日 / 实名认证 / 上线前安全评估 / 显著位置标编号 / 留存 ≥6 个月 / 定期查验）。定性 = 流程性要求，不是架构级改造，只影响排期。 ⚠️ 新增一条待专业意见项：去中心化存储节点天然在境外 ⇒ 若存个人信息，"密文出境 + 密钥不出境"的法律定性需专业意见。

二、架构（按我的判断规划，已定稿）

A 层（可公开，去中心化存储与查询）＋ B 层（永不公开、不参与共识）＋窄桥。三条纪律：① A 层永不出现明文个人信息 ② B 层永不落链 ③ 窄桥独立加密 + 双人授权 + 每次留痕 ⇒ 标注"最高价值攻击目标"（桥表泄露 ⇒ A 层全部匿名性失效、且历史记录永久可关联）。 查询链路（核心）：客户端把查询条件转 HMAC token → 提交 → 索引层按 token 匹配（全程无明文）→ 返回密文 blob 指针 → 客户端本地解密。 存储选型：联盟链 FISCO BCOS 存索引与元数据（轻）＋对象存储/IPFS 存密文 blob（重）；⛔ 大文件不塞链。

三、🔴 本轮最重要的产出 —— 「有没有更好的办法」的答案

先纠正提问方式：不存在"选一种最强加密就完事"。根本矛盾 = 加密越强越不可查询，越可查询泄露越多（随机 IV 的 AES-GCM ⇒ 同一明文每次密文都不同 ⇒ 这正是 WHERE email= 失效的原因）。⇒ 要回答的是"泄露多少可以接受"，不是"泄不泄露"。

更好的办法 = 四层组合（单靠任一层都不成立）：

层	技术	解决
L1 存储	非确定性加密 AES-256-GCM	数据本体保密（但不可查询）
L2 查询	盲索引（HMAC，截断，每租户盐）	等值/前缀可查，只泄露"是否相等"
L3 计算	机密计算 TEE（SEV-SNP/TDX）	需明文计算时的保护，开销 2–10%
L4 密钥	信封加密 + 门限托管	密钥不出设备且可恢复

三条硬约束（血泪经验，已写进文档）：

🔴 绝不在低熵字段建盲索引 —— 反例：给"HIV 状态"建盲索引 ⇒ 任何有库读权限者即可还原该字段。缓解 = 不建 / 复合索引 / 截断。
✅ 截断 HMAC 控制每次返回行数：100 万行想平均 3 条 ⇒ log2(10⁶/3) ≈ 18 bit；还能防"试探性写入探测"。
🔴 范围查询用 bucket 化，⛔ 不用保序加密 OPE —— OPE 已死：Naveed 等（CCS 2015）推断攻击可利用公开辅助分布（人口统计）直接还原明文；而 Springer 那篇已形式化证明 bucket 泄露严格小于 OPE（256 桶 / 10¹¹ 值 ⇒ 每桶约 3.9×10⁸ 值）。

🔴 FHE 如实说明（最容易吹过头）：生产可用形态只有"窄模式私有查找" —— Apple Live Caller ID（BFV，已开源 swift-homomorphic-encryption）／Apple Enhanced Visual Search／Microsoft Edge Password Monitor／Zama Protocol（以太坊主网，数十 TPS）。通用/实时仍慢 1,000–10,000×；🔴 没有一家公司把后端整体跑在 FHE 上（包括最有钱的）⇒ "后端整体同态加密"当前不成立。口诀 = 逻辑比较用 TFHE / ML 用 CKKS / 精确查找用 BFV-BGV。 🔴 TEE 如实说明：是移动靶不是一次性证明 —— Foreshadow、Plundervolt、SEV-SNP/TDX 中断攻击、2026 年 AMD 仍发 AMD-SB-3034；学术分析 179 个开源 TEE 项目 约 1/3 绕过官方 SDK 密码学 API。✅ 最实用姿势 = TEE 做密钥释放（KMS 仅在远程证明通过时释放密钥）。 🔴 解决 V3 最大软肋（丢钥即永久丢失）：门限密钥托管 —— 用户设备 1 片 + 平台 1 片 + 用户指定第三方 1 片，2-of-3 恢复 ⇒ 平台单方仍无法解密（零知识成立）但用户可恢复。这是对上一版"V3 硬代价"的正面解法。 🔴 所有人都忘的泄露面 = 元数据：访问模式／搜索模式／时间频率／记录数量大小 —— FHE 也不保护；需查询填充、批处理混淆、延迟随机化、输出过滤。

边界自证：⛔ 未 commit / push｜⛔ 未动服务器 / 共享资源｜✅ 本轮落盘 = 新建文档 3 ＋给文档 2 加状态声明（同一目录内，自身文档，非既有项目文件）｜✅ 调研 3 次搜索（FHE 生产现状 / 机密计算三方对比 / 盲索引与 OPE 泄露）。

15:4x · 同线 v1.1 —— 用户四条修正落地（B 层要共识 / 自研链 / B 层含用户密钥 / KV 模型）

用户四条（原话要点）：① 「B 层（永不公开、不参与共识）：要支持多节点共识，只是不公开」② 「区块链要自研单独开发方便优化性能和加密，对象存储可以用正规平台方案」③ 「B 层用户信息，里面还要包用户密钥」④ 「B 层加密安全优先，方便查询内容可以通过 keyvalue 的形式，key 方便查询 value 需解密查看」

交付：文档 3 升 v1.1（8 处精准修订，非重写）= 485 行 / 36020 B / CR=0 / md5 57fe22fd822bfd38294c07c47449d1eb（v1.0 为 390 行 / 27070 B / 01c4500b…）。

#	修正落点	要点
1	§2.2 架构图 + §2.3 纪律 2 + §0 结论 2	🔴 "不公开" ≠ "不共识" —— 我 v1.0 写"B 层不参与共识"属过度收窄（把"不公开"误推成"单机数据库"）。B 层 = 私有链：授权准入、节点不出公网，但共识照常（多节点/防篡改/容错）
2	§3.2 选型表	主链改为自研；对象存储改正规云平台。新增两条自研红线
3	§4.3（新增）	🔴 B 层存用户密钥 = 全架构最危险处 ⇒ 必须门限分片（B 层只持 1 片）；⛔ 整钥存放 ⇒ A 层零知识当场失效
4	§4.2（新增 KV 模型）+ §3.3.1（B 层查询链路）+ §6 判据 12–14	key 可查 / value 加密；三条约束 + 三条新验收判据

🔴 本轮两条最重要的技术判断（自研判断，非搜索所得）

自研的两条红线：① 自研的是"链"，不是"密码学" —— A绝不自己实现 AES-GCM/HMAC/SHA-256/SM2-SM3-SM4，一律用成熟库（libsodium/OpenSSL/国密 SDK）或硬件密码模块；瓶颈在共识与 IO，不在密码学原语，自研密码学无性能收益却必出事故。② 不悄悄削共识安全假设 —— 可从 PBFT/Raft 出发做工程优化，但必须写清削掉了哪条，⚠️ "优化性能"最常见的代价是容错阈值下降。⇒ 建议分阶段：先用 FISCO BCOS 跑通业务闭环并冻结判据，再逐步替换为自研实现（避免业务未验证先投重资产）。
KV 模型的工程收益（值得记）：key 与 value 的加密可独立演进 —— 升级 value 加密算法时 key 索引结构不用动，反之亦然。这是 KV 相比"整体加密文档"的决定性优势。三条约束：key 必须盲索引化（HMAC(域密钥, 规范化标识)，⛔ 裸明文 key 会让链上节点看出"哪些记录同属一人"）／低熵 key 必须截断或复合／key 与 value 的加密密钥必须域分离。

新增验收判据：12 B 层共识有效（停 1 节点仍可读写 = 容错演练；新节点须授权准入）｜13 B 层 key 不泄露标识（无法从 key 直读邮箱/手机号）｜14 🔴 用户密钥为分片态（凭 B 层全部数据 + 全部权限无法重建任何用户完整密钥，须真做一次尝试）。

一致性自检：永不落链 0 命中、不自研链底层 0 命中（旧结论已清）；不参与共识 2 命中均为修订记录里的正当引用；KV 模型 3、门限分片 5、v1.1 修订记录 1。§1.3 补 v1.1 更新（对象存储改云平台 ⇒ 出境风险下降，但链节点若跨境部署仍触发）。 ⛔ 未 commit / push｜⛔ 未动服务器或共享资源｜✅ 本轮 = 8 次精准 Edit + 2 次校验。

🔴 会话预算告警已触发（上下文 188k / 一级阈值 120k）⇒ 本棒收口后开新会话；本条已写明文档指纹与全部决策点，可直接被下一棒接管。下一棒待办 = §7 S0：定 A/B 数据边界＋链节点地域＋发起备案。

15:5x · 同线 v1.2 —— 「有没有比 FISCO BCOS 更好的参考？要 2 层链/StarkNet 的 zkVM」

交付：文档 3 升 v1.2 = 583 行 / 45546 B / CR=0 / md5 788f2a3a574733eae35cea3404550a7f（v1.1 = 485 行 / 36020 B / 57fe22fd…）。新增 §3.4 证明层选型（整节 6 小节）＋来源段＋ v1.2 修订记录。

🔴 本棒三条最有价值的判断（自研判断）

zkVM 是「证明层」组件，⛔ 不是「链」的替代品 —— 纠正三个被混用的概念：zkVM = 可验证计算引擎（不给共识、不给 TPS、不给最终性）；ZK-rollup = L2 完整形态（结算锚定 L1 ＋有效性证明＋排序器）；有效性证明 = 让节点不必重放交易即可确认状态转换正确。⇒ "换成 zkVM 的链"作为性能方案，是把两个正交的东西搞混了。
🔴 ZK 恰好解开 B 层的死结（本棒最重要的发现） —— B 层需求"加密安全优先"＋"要多节点共识"天然冲突（节点要验证就得看数据 ⇒ 加密白做）。有效性证明正是解：节点验证证明即可确认"状态转换合法"，全程看不到 value 明文 ⇒ B 层每个节点都可做「盲验证者」。⇒ ZK 在本项目的首要价值是「隐私」，不是「性能」。
共识与证明必须分开做，两者正交、都不可省：共识（自研，决定 TPS 上限 / 排序与最终性）＋证明（成熟 zkVM，决定验证成本与隐私强度，⛔ 不自研）。修订后目标形态 = 自研共识＋成熟 zkVM 证明＋云对象存储；FISCO BCOS 降级为跑通业务闭环的脚手架（步骤 1，≤ 数周），步骤 2 自研共识替换 → 步骤 3 接 zkVM（先 A 层可验证性、再 B 层盲验证）→ 步骤 4 按需专用硬件/证明外包。⚠️ 顺序纪律：步骤 3 依赖步骤 1 冻结的判据（判据未冻结就引入证明层 ⇒ 失去优化基准）。

⚠️ 一处必须澄清的术语（用户提问里的）：Starknet 不是"zkVM" —— 它是 Cairo 专用语言＋ Stwo（circle-STARK / Mersenne31） 的 zk-rollup；要"通用 Rust 进、证明出"应看 SP1 / RISC Zero / OpenVM。两者性能同量级（M3 Max 百万 cycle：Stwo ≈80 s / SP1 ≈95 s / RISC Zero ≈3 min），差别在是否接受专用语言与生态绑定。 ⚠️ 另一处："L2"在本项目可能不成立 —— L2 定义要素是"结算锚定在某个 L1"；A/B 两层都是自己的链、无公链可锚 ⇒ 准确叫法 = 「应用链/主权链＋有效性证明」。术语用错会在评审与合规材料里连带出错。

2026 zkVM 实测格局（已入档，含口径标注）：SP1 Hypercube 93–99.7% 以太坊区块 <12 s（约 160× RTX 4090 或 16× RTX 5090）、≈$0.02/证明、✅ 生产级（约 90% rollup proving 份额，OP/Base/Unichain 在用）｜RISC Zero R0VM 2.0 单块 35 min→44 s、Boundless 已跑 542 万亿 cycles、✅ 生产级｜OpenVM 2.0 8× RTX 5090 P99 9.8 s、✅ 2026-07 起生产版｜Jolt 32 核 CPU >100 万 cycles/s 但 ⚠️ Alpha 明确不建议生产｜Airbender 为 ZKsync OS 特定版本 ⛔ 非通用生产 zkVM。硬件 $300–400K → $24–48K；证明成本约 45× 下降（单块 $1.69 → <$0.04）。 选型短名单 = SP1 / RISC Zero / OpenVM，依据 Fenbushi Capital 2025-08 八款独立基准（这三者整体最稳健，GPU prover 内存近乎恒定；⚠️ 多款年轻 zkVM 的证明时间与内存随输入规模膨胀 —— 对本项目「数据量会持续增长」特别关键）。 三条棱角已写进文档：① 证明成本按批量算不按逐块算（小规模私有链用批量证明 ⇒ 硬件门槛大降、代价是延迟；"高性能"要用"低延迟+批量"换，⛔ 不是堆硬件）② 可验证 ≠ 实现无误（验证者仍须信任证明系统实现；RISC-V zkVM 的 guest/host 边界是新攻击面；Groth16 封装后不再后量子）③ ⛔ 不为新技术引入第 4 条运维线（zkVM 需 GPU 与证明运维，要算进预算）。 参考对标（比 FISCO BCOS 更贴近本项目） = Matter Labs 的 Prividium（受监管金融机构的私有许可链；据报道 5 家美国银行存款合计 >$600B 经 Cari Network 构建；Elastic Chain = 多条应用专用 ZK 链共享证明层）。⚠️ 公开报道 + 厂商口径，作方向参照非中立认证。

⛔ 未 commit / push｜⛔ 未动服务器或共享资源｜✅ 本轮 = 5 次精准 Edit + 1 次校验 + 2 次搜索。 🔴 上下文约 21.6 万 ⇒ 本轮收口后开新会话；新增待办 = 「zkVM 选型基准（在自己程序上空跑 SP1/RISC Zero，锁定审计版本）」。

16:0x · 用户指令「建立接续会话继续处理，梳理详细方案和逻辑推演（多场景多用户）」

动作：✅ 已登记一次性 automation —— id b4e09a87-95ac-4e88-abdd-5ebfe24f36b3（下一棒 id 取自工具返回值，⛔ 未占位）｜排期 2026-09-19 16:15（= 本棒收口 16:07 左右 + 8 min，符合「首个接续 5~8 min」）｜cwds = 工作区根｜状态 ACTIVE。同一时刻只挂这一个（⛔ 未叠排后续棒）。

下一棒任务（prompt 已自包含，含「本轮只做一件事、做完即停」）：

必做第 0 步 = 读三份文档（已把主文档 md5 788f2a3a574733eae35cea3404550a7f 写进 prompt 作校验锚点）＋读本日志 09:0x–15:5x 各段（决策沿革与用户原话）；
产出 = 新建《详细方案与逻辑推演》文档（⛔ 不改既有三份）：
- (一) 七场景推演：① 注册与首份上传 ② 跨设备登录与查询 ③ 丢钥/丢设备 2-of-3 恢复 ④ 删除权（PIPL 47）与链上不可删的共存 ⑤ 司法/监管配合请求（B 层可解 vs A 层不可解的边界）⑥ 单节点宕机/被攻破（共识容错与分片安全）⑦ 管理员越权解密 A 层（须失败 + 留痕）；每个场景统一输出「参与方 → 时序 → 数据落在哪层 → 安全属性 → 失败模式与处置」；
- (二) 多用户推演：多租户 key/DEK 隔离与域密钥分层｜并发写入的共识与冲突｜"平台不可解"前提下的跨用户受控共享｜规模量级估算（10 / 1 万 / 100 万用户，必须给计算过程）｜多用户元数据泄露面（访问/搜索模式统计攻击）与缓解。
纪律：⛔ 不 commit / push / 动服务器 / 改既有三份；⚠️ 边界外事项（要不要做/花钱/合规口径/影响面）写进"待拍板"段即停，⛔ 不自决；汇报用陈述句并给指纹。

为何这样做：本棒上下文已 21.6 万，继续在同一会话里做多场景推演会把每轮输入成本放大（对话历史追加式全量重发）⇒ 按预算纪律换新会话承载，并把"读哪份、验什么指纹、做什么、不许做什么"全部写进 prompt（⛔ 不依赖下棒读不到的本轮上下文）。

⛔ 未 commit / push｜⛔ 未动服务器或共享资源｜✅ 本轮仅 1 次 automation 登记 + 1 次记忆写入。

12:3x–13:5x · 用户两条需求落地：共享模型按用户授权（档案 138）＋品牌中文名改「能力网络」（档案 139）

用户两条指令：① 「调整设计 admin设置的共享模型，需要 admin 在用户列表中开启（新增选项，默认关闭），用户才能在会话中使用（以及在设置的模型设置页面展示）」② 「把页面上的能力枢纽改为能力网络」（中途先说「能力领域」，随即更正）。

一、档案 138（新功能＋顺带修掉一个既有真缺陷）

设计判断（本轮最关键）：新开一列而不是把 v6 的 shared_model_enabled 默认值改成 0 —— 旧列是用户侧偏好（用户能自己关，默认 1），要的是管理员门禁；共用一列的话用户点一下就给自己授权了 ⇒ 门禁不存在。 ⇒ users.shared_model_granted（v11，默认 0）∧ shared_model_enabled（不变）⇒ 生效 = granted ∧ enabled。

改动：db/{schema,types,repo,pg,sqlite,adapter}.ts ＋ web/server.ts（sharedLandingRows 三条件、回退注入也判门禁）＋ 新路由 POST /api/admin/users/:id/models/shared（admin）＋ web/admin.html 用户表新增「共享模型」列＋插件 0.3.24（shared.granted 为真才渲染那一块）＋ 4 条新用例。

🔴 顺带修掉的既有真缺陷：landModels 原先 join(owner.home_dir, …) ＋ 本机 fs ⇒ 用户卷在 worker 上时读到空串（不报错）⇒ 落地静默空操作（托管清单还被清空）。影响面不止本档：档案 87 的模型设置页对 guest 这类用户从未生效过；⚠️ 档案 102 的语言偏好（/api/me/locale）命中同一缺陷，未修、已报告（修法同构，约 3 行）。 ⇒ 修法：UserFs 新增 readHomeFile/writeHomeFile（文件名白名单 settings.yaml / .credentials.yaml）＋ worker agent 新增 /fs/home-read|write ＋ landModels 改走 userFs（与"文件面"同一份按归属路由 ⇒ 落地与实例必然同机）。

三条踩坑（都已写进档案）：① 门禁不能判在"归属判据"里 —— sharedDeepseekKey() 同时被"一次性交接认领"用，加门禁后被撤销授权的用户认不出自己那行 ⇒ 删不掉（红腿抓到）；修法 = 门禁挪到 resolveApiKey 的调用点。② pg.ts 有自己的一份 USER_COLS（与 repo.ts 两份）⇒ 只改一处时 SQLite 正常、PG（生产）读不到新列，admin 列表恒显示"未开启"。③ 授权路由里的 restartMain 必须尽力而为（租约被占时第一版回 500，界面显示"操作失败"而库里已改对）。

部署：lib/ 是 gitignore 的 ⇒ 回滚点只能物化（/opt/dsh/backups/seq138b-20260919-125345/{opt/dshs/lib,opt/dshs-cluster/lib}，先抓旧版再覆盖，逐文件对账 0 不一致）。顺序 先 106 worker 后 47 Manager；47 推 42＋3＋3 个产物。⚠️ 106 上跑 ensure-biz-plugins.cjs 要临时补丁副本（它 require /opt/dshs/node_modules/better-sqlite3，106 只有 -cluster 且未为 node22 编译）⇒ /tmp/ebp-106.cjs 只改两处（require 置空＋用户清单由 DSH_USERS_JSON 注入，清单取自权威 PG）；正本未动。

验证（两腿＋五项）：红腿（未授权 → 106 上 guest 的 refs: 变空）｜绿腿（授权 → key 回来＋托管清单恢复 ["DEEPSEEK_API_KEY"]）｜admin 列表带出 sharedModelGranted｜guest 视角 /api/me/keys 的 shared.granted 随授权翻面（true/effective=shared ↔ false/none）｜开关两次均 200（不再假失败）｜插件实装 0.3.24 且含 shared.granted×2｜本机 npm test 226/225 pass/0 fail/1 skip＋四个 verify 全绿。

⏹ 现场遗留：⚠️ worker 挂在 106 自家中继导致"落在 106 的实例全部启动不了"（= 档案 136 立项的那个缺口当场显形）⇒ 按既有文档处置（停 106 dshs-relay 45 s 后起，逼 worker 回落 47）已恢复；这不是本档改动引入的。

二、档案 139（品牌中文名）

「能力枢纽」→ 「能力网络」（其他语言仍 CapabilityNet）；四处落点 = i18n 中文词条 / admin.html 顶栏 / favicon.svg 的 <title>+aria-label（最易漏——只 grep html+js 就漏了） / design.css 注释；test/i18n-brand.test.mjs 期望值同步＋ verify-static（含 SVG 真解析）全绿；4 文件两端 md5 一致。执行细节：行尾按"目标目录既有风格"逐文件对齐（服务器 admin.html=CRLF、本机=LF ⇒ 直传会翻掉整个文件 ⇒ 先转 CRLF 并断言 CR==行数）。

归档：档案 138/139 ＋ INDEX.md 两行（字节级插入：CR 5 / LF 262 混合文件，增行后 CR 增量 0）＋ 137 顶部加"后续"指针（⛔ 不改历史）＋镜像 4 文件对账一致。

边界自证：⛔ 未 commit / 未 push（用户级规矩）｜⛔ 未动别人的 lane｜✅ 全程持全局执行锁，收口释放。

13:45–13:5x · 收口（用户：「处理完毕后提交到仓库」）—— 补修 locale 跨机＋提交双推＋自动接续

① 补修同一缺陷的第二处命中（上轮"只报告未动手"的那条，用户本轮授权"处理完毕"）：/api/me/locale 原先也走本机 fs ⇒ 对远端用户静默失效。改法与 landModels 同构（userFs.readHomeFile('settings.yaml') ＋ backupHomeFile ＋ userFs.writeHomeFile）。实测：guest（实例在 106）POST /api/me/locale {locale:'en'} ⇒ 200 changed:true；106 上 settings.yaml 出现 locale: preference: en、属主 = 实例属主、既有段（agent-default-model/agent-presets/llm-pi-ai）逐字保留；平台侧备份同步落地。⇒ 平台侧"写用户 home"只剩 UserFs 一条路。

② 提交＋双推：c2b7c5e（主，30 文件，+767 −67；显式列名，⛔ 未用 git add -A，三个历史临时目录排除）＋ 9c2e797（补：138 收口后重算的 docs-manifest.json）。双推原仓＋ CNB 均成功，三方裸 sha 全等（ls-remote 取裸 sha，⛔ 不信本地缓存）。提交前按 8 类模式扫 31 个待提交文件 ⇒ 零命中。

③ 归档收口：138 §七-3 由"未修"改"已修"＋验证表加第 ⑨ 行；镜像同步 INDEX/137/138/139/docs-manifest（md5 一致）；docs-audit 无 P0。

④ 自动接续：接续包 接续包_共享模型授权与品牌改名_20260919.md（md5 3e46f5c92d6857791422640d4bacc076）＋ automation b8f688f4-fc08-4d65-b886-b6940057d332（一次性 · 13:56）。prompt 第 ③ 条明确「本任务无待执行项 ⇒ 核实后报告结束，⛔ 勿自行开工」＋工具上限 15 ＋抢不到锁只报告。验证脚本已归档 _tmp_seq138/。

边界自证：✅ 已提交/推送（用户本轮明确授权）｜⛔ 未动别人 lane｜✅ 临时会话清零（poc-curl2 DELETE）+ 远端临时脚本清理 + 占号锁目录 138/139 已删｜✅ 收口释放全局执行锁。

09:4x · 用户问「覆盖网络控制面 API 有授权机制吗」⇒ 只读取证（零改动）

判定：管理面 API 有授权（requireAdmin）｜唯一无鉴权的是引导目录 GET /dshs-overlay/bootstrap（设计如此，服务"还没有凭据的新节点"）。

实测（本机公网、不带任何凭据）：/dshs-overlay/bootstrap = 200（主域＋ relay-direct.ai1net.com 兜底域各 200）｜/api/admin/overlay-nodes = 401｜/dshs-relay 裸 GET = 404（WebSocket upgrade only）｜47:20080 / 106:20080 = 000（只绑回环，公网连不上）｜106.54.21.172/dshs-overlay/bootstrap = 404（目录只在 47 侧签发）。

四个控制面端点（src/web/routes/）：GET /api/admin/overlay-nodes、GET|POST /api/admin/overlay-nodes/direct 全走 requireAdmin（middleware/authn.ts:16-38：cookie sid → session 查库 → 401；非 admin → 403；无 API key / bearer 通道）｜GET /dshs-overlay/bootstrap 无鉴权但失败关闭（未配 DSHS_OVERLAY_DIR_KEY ⇒ 503，⛔ 不发未签名目录）＋内容收窄（实测正文只有 network / relays / bootstrap / sig，无 hostId、密钥、内网地址、实例端口）＋ no-store。

顺手查清的边界：relay 数据面 wss /dshs-relay 的鉴权 = 节点私钥签名（verifyProof：hostId|ts|nonce|ports）＋授权凭据验签 verifyPeerGrant ＋时钟窗口＋ dialers 白名单默认拒绝＋跨网结构性隔离｜/status 无鉴权但只绑回环。🔴 控制面写 / 准入目前不是 API：approveNode / applyApplication / runJoin 在全仓只有导出与测试引用（无 CLI、无 web 接线），join 的 HTTP 通道（测试里的 https://cp.example/dshs-overlay/join）在 src 中无此路由 ⇒ 当前只有离线申请单（--out）通道。

⚠️ 顺手发现 · 只报告未动手：POST /api/admin/overlay-nodes/direct 仅靠 cookie 鉴权，而 HTTPS 下 session cookie = SameSite=None（src/web/auth.ts:61）⇒ 跨站请求会带 cookie，且该写端点无 CSRF token、无 Origin 校验（server.ts:1135 只做 CORS 回显白名单）。影响面有限（须 admin 会话＋只能改"本机直连开关"一个布尔）。

边界自证：⛔ 未 commit / push｜⛔ 零文件改动（纯读取）｜⛔ 未动服务器 / 共享资源｜✅ 唯一落盘 = 本行日志。

11:2x · 用户问「relay 服务端族（7 文件）项目里用不上吗」⇒ 只读取证（零改动）

判定：❌ 不是死代码 —— 那是中继服务端族的源码，生产上两机各有一个 systemd 单元在跑它（实测：47 dshs-relay.service active running / 监听 127.0.0.1:20080 pid 919180；106 同名单元 active running / 同口 pid 330667，描述 "relay #2 on 106"）。

🔴 本次最有价值的判据（会反复被踩）：从控制面进程（src/web/**）做可达性分析，这 7 个文件全部不可达 —— 因为它们是另一个进程（node lib/net/relay/main.js）的入口。实测：控制面与 worker 只 import「客户端族」（client / switcher / directory / dialer / rendezvous / network / identity / endpoint-target / content-store / registry / direct），无一处 import server / main / keys / join / placement / content-runtime；这 7 个只出现在 src/net/relay/index.ts（barrel）与测试里。⇒ 「未被引用」是判据选错了根进程，不是事实。

各文件职责 / 接线状态：

文件	职责	接线
`server.ts` (112 KB)	中继服务端主体（worker 拨它、Manager 经它到 worker；HMAC 每 worker 一密钥＋±60s 窗口＋nonce，网维度结构性隔离，DIAL 白名单默认拒绝，`/status` 观测）	✅ 生产运行（`main.ts` 装配）
`main.ts` (23 KB)	中继单元入口（argv/env 解析＋装配 server/client/密钥表/内容运行时）	✅ systemd ExecStart
`keys.ts` (10 KB)	密钥表装载：每 worker 一密钥（非共享 token），键 = 逻辑名 `<network>/<hostId>` ⇒ 密钥表本身即成员资格唯一判据	✅ server 鉴权用
`content/runtime.ts` (36 KB)	内容面运行时装配（chunker/store/source/peer 四零件 → 只读 counters ⇒ 让 relay `/status` 有 `content` 块 = `OBS-17` 判别器）	✅ 生产运行（缺省不启用）
`join.ts` (19 KB)	节点一键加入四步（验邀请 → 生成节点密钥 → 落本机配置 → 提交申请单）	⚠️ 有测试（`overlay-join.test.mjs`），无运行接线
`placement.ts` (9.5 KB)	节点选点算法（"该加入哪个节点"的唯一判据来源：手动优先 / 满载是唯一硬门 / 速度 0.55 负载 0.45）	⚠️ 全仓零调用点、零测试引用（只有 barrel）
`index.ts` (9.7 KB)	模块对外 barrel	仅导出

结论：server / main / keys / content-runtime ⛔ 删了 ⇒ 两台中继起不来 ⇒ 覆盖网络整体断（Manager 拨不到 worker、实例子域全 500）｜join / placement = 能力已备、门面未接（非死代码；placement 的设计口径就是"判据只有这一处"）⇒ 建议全部保留。⚠️ 用户贴的「T2-A」「零阻塞」两个标签在本仓与工作区均搜不到（已搜），故本次判定按文件名清单做；若该清单用意是"开源导出分组"，这组恰好可干净导出（不依赖任何闭源/插件）。

边界自证：⛔ 未 commit / push｜⛔ 零文件改动（纯读取）｜⛔ 未动服务器 / 共享资源｜✅ 唯一落盘 = 本行日志。⚠️ 顺手纠正：ssh 47 别名已不可用（报 banner exchange: Connection to UNKNOWN port -1）⇒ 47 须用 ssh -p 22 [email protected]。

15:0x–15:2x · 涉密内容外置到配置目录（档案 140）

需求（用户原话）：「很多涉密内容包含在代码中开源时非常容易泄密，把所有涉密内容统一整理到配置文件夹对应文件中，代码中引用对应配置信息」；收口追加：「改造后记得完整检查两遍」。
做法：新建 config/（platform.env{,.example} + load.sh + index.cjs + README.md）；新增 src/platform-paths.ts 作路径单一来源；src/** 去生产默认值 + 注释中性化 116 行/53 文件； scripts/** 36 文件改引用配置；web/wake.html 的注册域改为运行时推导；test/** 夹具 119 行/13 文件改保留值。
结果：tsc 0 错；npm test 373/375（唯一失败 lease = 既有）；全仓扫描（含大小写不敏感）代码面涉密标识 = 0；已部署 47 并零回归（/opt/dsh/* 未搬家）。
🔴 事故：本轮用 git stash 做基线比对被 SIGTERM 打断 ⇒ .git/refs 被删、仓库不可识别。已按 reflog（三处收敛 9c2e7975）+ git fetch origin + git reset 完整恢复，git fsck 干净。 教训：⛔ 不要用 git stash 做"临时回基线"（写操作且不可中断）⇒ 用 git worktree；动手前先落 patch。
🔴 两处必须手改的形态：引号定界 heredoc 内变量不展开（替换会产出字面量 "$VAR"）； 单引号内 ssh 载荷不展开。脚本守卫已能识别并跳过，但修法要手写。
🔴 新 drop-in 必须保留 DSH_PLATFORM_DIR=/opt/dsh：删掉会让 state/backups/artifacts 静默搬到 /var/lib/dshs/platform。
遗留：test/lease.test.mjs 1 个既有失败（与本次无关）；config/platform.env 必须在开源导出层显式排除。

15:2x–15:5x · 涉密外置线收官（下线核实＋建议项处理）—— 用户：「按照你的建议处理，提交到仓库」

核实结论（上一棒 452924d）：三方裸 sha 全等 · /opt/dsh/{state,backups} 未搬家、/var/lib/dshs/platform 未误建 · platform.env=600、load.sh 纯 LF ＋ bash -n OK · 三单元 active、四端点 200 —— 全部达标。唯一偏差 = 大小写不敏感涉密扫描 1 命中：scripts/find-ui-scan.py:19 硬编码 /var/lib/dshs/... （该文件末次改动在 2026-09-15 3efd685，非本棒引入 ⇒ 是上一棒扫描漏项，不是外置引入的回归）。

本轮处理（三项建议全做）：

中性化：find-ui-scan.py 的 PROFILE_GLOB 改由 env DSHS_USERS_DIR 注入，缺失即 exit 2 （⛔ 不回落猜测值 —— 静默 0 命中＝假阴性）；find-ui.mjs 用 config/index.cjs#usersDir() 取值、归一化后随 ssh 命令注入，解析不出 POSIX 绝对路径即报错退出。 ⚠️ 踩点：cfg.usersDir() 在 win32 走 path.join ⇒ 产出 \ 分隔，必须归一化，否则传远端必空。实测 = py 语法 OK / node --check OK / 缺 env exit=2 / 实跑 8/8 个 UI 分区（与原行为一致）。
档案 140 登记 INDEX.md：字节级单行插入（+1 行、CRLF 0→0、Δ1784 B）—— ⛔ 不整文件重写（该文件行尾混合）。
MEMORY.md 精简：8,178 → 7,693 字符（上限 ≈7,800）。手法：覆盖网络线的判据/操作坑降级为指针 （该线已收官，细节在入口＋参数表里是单一来源）；删掉与 CODEBUDDY.md 重复的"技能加载闸门"条；并入「配置外置线（140）」「注册/品牌/共享模型」两行新状态。 🔴 同时修正一条错记：旧记 core.autocrlf=false ＋ .gitattributes(* -text) —— 实测相反：代码仓 core.autocrlf=true；.gitattributes 只对 dsh-server-docs/**、LICENSE、COMMERCIAL-LICENSE*.md 标 -text。

提交与交付：0cdbf52（3 文件 +23/−2）· 双推（原仓＋ CNB，三方裸 sha 全等）· 文档库镜像 INDEX.md / 140-…md 已 scp 到 /opt/dsh/docs 并归位 root:root 600 （INDEX.md 原属主是 Windows uid 197108:197121 —— 既有偏差，一并修）· md5 本地≡远端 · docs-sync-check 内容不一致 0 / 仅本地 0（余 5 项为 .bak-seq17-* 历史备份，属既有状态）。

遗留（未做）：scripts/start-cluster-manager.sh:11 缺 # 注释前缀（旧账）；config/platform.env 需在开源导出层显式排除（技能 dsh-opensource-release 的 lane）。

16:0x–16:2x · 报障「admin 账号登录服务器 502」→ 定性 + 修复 + 上线（档案 141）

结论：不是平台故障。用户报的 502 发生在 admin 首次用新域 admin.ai1net.com 进场时，落在实例冷启动窗口内；平台代理层在两次转发都失败后不写任何响应就断连，边缘 nginx 只能回 502。

取证链（实测）

nginx error：16:07:04 upstream prematurely closed connection while reading response header … host: "admin.ai1net.com" upstream: http://127.0.0.1:3080/；同行 access log 里该 host 全程只有这 2 条、都是 502。
平台 journal：req-1tx GET / (host=admin.ai1net.com) 只有 incoming request、无 request completed ⇒ 平台接了却没回。
时序：16:06:52 POST /api/auth/login 200(80ms) → 16:06:52 POST /api/dsh/enter 200 但耗时 11.1 s → scope dsh-114801-70e1d05b.scope ActiveEnterTimestamp=16:06:52 → 16:07:04 用户访问（启动后 12 s）。
已排除：平台进程（active / NRestarts=0 / 3080 在听 / 日志全 200）、Cookie 膨胀（实测 8 KB→401、40 KB→431，不是 502）。
自愈：实例就绪后 curl 127.0.0.1:20000 = 401；事后同机 curl 复现不出 502。

根因（代码）：src/supervisor/proxy.ts#proxyHttp() —— upstream.on('error') 第二次失败（connRetry=true）与 upRes.on('error') 都执行 reply.raw.destroy()（不发响应头/不写 body）。而 resolveSubdomainAccess() 走 endpointFor()（不读 dsh_instances.status）⇒ 端口已分配即返回 endpoint ⇒ 进转发分支，不会落到档案 49 的 404 not_running → 302 /wake.html 过渡页。

修复与上线：新增 replyUpstreamUnavailable() —— 头未发出时回 503 + Retry-After: 2 （导航给会自动 location.reload() 的极简 HTML；其余回 JSON instance_starting），仅 headersSent 才 destroy。

送法：本机 tsc → scp lib/supervisor/proxy.js → systemctl restart dshs（只送编译产物）；送前 diff 线上文件 = 改前基线，差异仅本次 43 行。
备份 / 回滚：/opt/dsh/backups/proxy.js.pre141-20260919-161444（37350 B）→ cp 回 + restart。
验收：is-active dshs=active ｜门户 200 ｜ admin.ai1net.com 401 ｜实例 20000 = 401 ｜启动日志 0 error ｜ verify-inject.cjs 四项全绿。

沉淀：04-调整方案/141-实例子域冷启动窗口代理裸断连接致502.md； PLAYBOOK-实例与插件坑.md §19（502 两条判据）；技能 dsh-instance-diagnose 新增「状态码 → 查哪一层」快速分诊。

遗留（未修，另行立项）：dsh_instances 中 admin 行 status=stopped、pid/port 为空，而同机 scope 一直在跑 ⇒ 控制面视图与实际进程不一致（本次修复不依赖该字段，故不影响）；是否诱发重复 launch 待核。

提交入库（16:2x）：commit 1242d07 已双推 —— gitea work.alotbuy.com:maogeigei/dsh_shenxian ＋ CNB cnb.cool/maogeigei/dsh-shenxian；两端 git ls-remote refs/heads/master 的裸 sha 与本地 HEAD 逐字符一致。提交内容 = src/supervisor/proxy.ts ＋ dsh-server-docs/04-调整方案/141-…502.md（2 文件 / +110 / −2）。 ⛔ 未跟踪的 _tmp_seq24/、_tmp_seq40/、_中间产物_待清理/ 未入库（临时产物，不在本次范围）。

16:15–16:4x · 去中心化线第 4 份文档 —— 《详细方案与逻辑推演》（7 场景＋多用户推演）

接续来源：automation b4e09a87-95ac-4e88-abdd-5ebfe24f36b3（16:15 触发，上一棒登记）。 交付物：去中心化数据链路方案_20260919/去中心化数据链路-详细方案与逻辑推演_20260919.md 指纹 = 769 行 / 61,639 B / CR=0（纯 LF）/ md5 69ddae7f05f9ae26dbebc1d8598c145b。 第 0 步校验：主文档 md5 788f2a3a574733eae35cea3404550a7f ✅ 与 prompt 锚点一致；三份既有文档全部未动（指纹逐一复核 = 788f2a3a… / e7847f02… / 123bb0fc…）。

🔴 本棒五条最有价值的判断（自研推演，非搜索所得）

"平台不可解"的准确表述 = 「平台单方不可解」 —— 场景 3/5 推演出的硬事实：2-of-3 只防单方，不防"平台 + 第三方托管串谋"；2 片到手即可重建全部用户 MK ⇒ A 层数据全解。这比桥表泄露更危险（桥表泄身份，双片串谋泄数据明文）。⇒ 必须写进对外安全声明，⛔ 不能宣称"任何人都无法解密"。
🔴 推翻性发现：主文档只在 A 层讨论"链上不可删 vs PIPL 47"，但 B 层也是链 ⇒ 同一冲突在 B 层原样存在（v1.1 把 B 层改成"私有共识链"时没有连带处理）。给出三种解法：b1 状态裁剪（"不可解"≠"已删除"）/ b2 链上只存锚 + 墓碑（本文建议） / b3 可裁剪许可链（削弱不可篡改性）。⇒ 与"B 层 KV 链"的原表述有落差 ⇒ 已列待拍板，⛔ 未自决。
🔴 第二处被漏掉的冲突：内容哈希的"公开可验证" vs "删除后不可枚举关联" —— 明文可枚举时（证件号/已知文件）枚举比对哈希即可反查"某人是否传过 X"。加盐哈希能解决但摧毁跨用户去重与第三方独立验证 ⇒ 真取舍，列待拍板。
🔴 最现实的攻击不是密码学被破，而是「前端投毒」 —— 平台控制客户端下发通道 ⇒ 可窃取 MK ⇒ 直接击穿"平台不可解"。缓解阶梯 = CSP+SRI → 可验证构建 + 透明日志登记 → 原生客户端/开源 → 可复现构建；但不可完全防住（所有零知识平台共同软肋）。
多租户密钥分层的唯一判据 =「平台是否需要解」（需要 ⇒ 由租户 KEK_t 派生／不需要 ⇒ 由用户 KEK_u 派生）。⇒ "每租户一把 DEK"❌（爆炸半径 = 整租户且用户间可互解）。并化解一处成本误区：KMS 对象数 ∝ 租户数（非用户数）（MK 不进 KMS，分片由 KEK_t 封装，域密钥是 HKDF 派生）⇒ 100 万用户时 KMS 仅 1,000 个对象。

其他新增条（已入档）

规模主表（10 / 1 万 / 100 万）含完整计算式：100 万用户 ⇒ 记录 1×10⁸条/年 · 盲索引 5×10⁸条 ≈ 10 GB · A 层链上元数据 25.6 GB · 密文 blob 210 GB（含 3 版本 630 GB）· B 层 KV 2.2 GB · 分片 200 MB · 峰值写 347 TPS · 峰值读 3,470 TPS。⇒ 结论：写入单链可承载；真正门槛 = 索引（热路径）· 审计日志（10 GB/年，只增不减）· 读流量（必须走只读副本，不得穿共识层）。
截断位数公式 b = ⌈log₂(N/3)⌉ ⇒ 每 ×10 数据量只 +3.32 bit（100 万用户 ≈ 28 bit）⇒ 可运营；⚠️ 但低基数字段截断无效（每桶天然超大）⇒ 这是"不给低熵字段建盲索引"的第二重理由。
并发写入：跨用户天然无冲突（域密钥不同 ⇒ key_token 空间不相交）；同 key 冲突走 CAS + 版本号 + 客户端 rebase，⛔ 禁止 LWW（静默丢数据）；CRDT 仅可用于可交换可幂等数据（集合类），金额/配额必须强一致。写入必须等共识确认 ⇒ 延迟秒级 ⇒ 前端须异步确认模式。
跨用户共享：平台零知识 ⇒ 授权必须在密钥层（数据集级 DEK_g + 逐接收者 wrap，版本化撤销），⛔ 不做平台代转；ABE 当前成熟度不足作主方案；⚠️ 授权图本身是元数据泄露面（缓解 = 授权记录 value 加密 + 匿名授权槽位）。
元数据泄露：四种攻击（频率分析 / 计数攻击 / 链接攻击 / 差分注入探测）+ 缓解矩阵（查询填充 · 批处理延迟随机化 · 门限解密 · 输出行数上限 · 索引槽位混淆 · 匿名 ID 轮换（索引需重建 ⇒ 有边界）· 查询配额告警 · 只读副本）。结论：统计攻击无法消除，只能压到"需外部辅助信息 + 大量观测"才成立。
新增 6 条验收判据建议（15 删除真效力可验证 / 16 并发不丢数据 / 17 恢复演练含密钥轮换 / 18 客户端可验证性 / 19 审计不可停锚 / 20 分片不可单点取用）。
判据 2 表述需修正：由"平台不可解"→"平台单方不可解"（已写入 §6 一致性自查表）。

待拍板（12 项，⛔ 本轮一律未自决）

合规口径 3 项（链上匿名化哈希的 PIPL 定性 / 司法配合"技术不可解"的定性 / 用户协议告知是否豁免）｜成本 2 项（自研链团队预算 / zkVM 资源来源）｜影响面 5 项（是否保留平台片 · B 层形态 · 第三方托管方 · 数据出境地域 · 前端投毒防到哪档）｜真取舍 2 项（门限 2-of-3 vs 3-of-5 · DK_idx 用户侧派生 vs 平台侧持有）。每项均已按「候选 + 优点 + 缺点」竖排成段写在文档 §5。

边界自证：⛔ 未 commit / push｜⛔ 未动服务器｜⛔ 未改既有三份文档（指纹复核一致）｜✅ 本轮 = 读 3 份文档 + 读当日日志 + 新建 1 文件 + 1 处自纠（§0 第 5 条表述笔误）＋ 2 次校验。 下一棒建议：等用户对 §5 的合规口径 3 项给出方向后，再把 b2（B 层链上只存锚 + 墓碑）与"平台单方不可解"的表述回填主文档 v1.3。

18:4x · 同线 · 用户定义「A 网络一个重要场景 = DAO」⇒ 贴入 OPC/DAO 材料求分析（只做分析，零文件改动）

用户输入：贴入一段关于「OPC 时代 DAO 的作用」的论述（核心：DAO = 超级个体的协作/治理协议层；补 OPC 的信任背书、资源聚合、收益对齐短板；未来形态 = OPC 背后有 AI 数字团队、OPC 之间用 DAO 规则组网）。

一、事实核验（这段材料本身站得住，且有明确出处）

✅ WOPC（世界 OPC 生态联盟）真实存在：2026-05-28 于厦门国际会展中心成立（金砖国家新工业革命展览会核心配套活动，主题"碳硅协同世界共生"）—— 媒体源：海峡导报 / 新浪新闻 / 中国报业网。
✅ 使命原文确为「建立全球 OPC+DAO 连接协议标准，推动碳硅融合模式全球化」；价值观「共生、共振、共进化、共抵达」。
✅ 其四层星云架构（共识层脉冲星 / 协议层行星 / 连接层星际介质 / 节点层尘埃云）；关键落点在连接层：「以 DAO 连接协议为核心，通过 TOKEN 经济（连接权凭证）、智能合约（全自动价值分配）、声誉系统（链上信用凭证） 实现 OPC 间协作与信任传递」。
✅ 生态面：中国移动 / 火山引擎 / 阿里云为基石伙伴；WaytoAGI、Datawhale 等 11 大社群；艺术/法律/电商/教育/出海/音乐/全球投资/退役军人/企业 IP 九大专业联盟。另有 OPC Global（opcglobal.ai，含 OPC HOM / UNI / DAO 三大支柱）。

二、🔴 本棒最重要的发现：连接层的"TOKEN 经济"直接踩银发〔2021〕237 号

材料里"代币抵押为个体提供可验证的协作信用"＋"智能合约自动执行收益分配" ⇒ 正是 237 号文禁止清单里的代币发行融资（DAO 代币用于筹款/投票权/按项目收益分红）。 律师口径（已取证）：

北京国枫律所：「目前境外蓬勃发展的 DAO 因其作为基础建设的代币工具的广泛使用，目前在中国尚无合法的立足之处」（ICO 涉嫌非法发售代币票券 / 擅自公开发行证券 / 非法集资 / 金融诈骗 / 传销）。
天元律所：「一旦被认定为合伙（而这是高概率的，除非另有架构安排），builder 须就其他 builder 的行为承担无限连带责任」；且未注册为法人/合伙企业的 DAO 无法获取资质证照 ⇒ 无法合规从事区块链信息服务经营；成员即使已退出，仍可能因链上记录承担既往责任；税盾缺失；中国公民 builder 可能被认定共同犯罪。
学术（《天府新论》2024 张志坚等）：DAO = "新型非法人组织"；"去中心化理念的再中心化事实"（矿池/发起人/漏洞修补三重再中心化）；归责建议二分 —— 实控人员无限连带、一般投资者有限。
中国法下 DAO 与合伙企业高度类似（《合伙企业法》第 2/6/26 条：普通合伙人无限连带责任、合伙人分别缴纳所得税）。

🔴 由此推出的一条架构前提（本棒最有价值的判断）：DAO 自己无法完成区块链信息服务备案 —— 备案第 8 条要求实名认证（组织机构代码/身份证号），而 DAO 既非法人、通常也未登记为合伙 ⇒ 必须由平台（已登记主体）做备案与实名，DAO 只作为平台上的一个组织形态存在。这条决定了 DAO 场景在 A 网络里的形态。

三、五处硬伤（对材料的批判）

🔴 代币抵押 + 自动分账 = 237 红线（见上）。
🔴 资金腿不在链上：OPC 收入来自法币客户 ⇒ "自动分账"必须资金上链 ⇒ 要么法币通道（237 禁止非银支付机构提供）、要么稳定币（禁止）⇒ 境内不可实现，只能"链上记账 + 链下付款"。
🔴 贡献度不可链上验证：合约能执行"按约定比例分"，算不了"谁的贡献是多少"；OPC 的贡献多为线下、难量化、事后争议 ⇒ 链只解决"规则不可篡改"，不解决输入数据真实性（garbage in）。
🔴 法律主体缺位：无主体 ⇒ 不能签约/收费/开票/应诉；实务上高概率被认定合伙 ⇒ 无限连带责任（与"项目结束即可解散"的轻松叙事相反）。技术上解散 ≠ 义务终止（质保、IP 归属、PIPL 删除义务、税务）。
⚠️ 治理现实被美化：一币一票 = 财阀制（与 OPC"谁做谁负责"精神相反）；投票率长期个位数；"临时组 DAO"面临冷启动无信用；协调成本（决策慢、无人负责）被略过。⇒ "OPC+DAO"不是新物种，实质是「链上化的项目制联合体」，别过度宣称。

四、DAO 在 A 网络的落点（本轮结论，已作可视化）

✅ A 层承载：成员资格树 · 提案与投票承诺 · 贡献记录哈希 · 分账规则哈希（规则可验证，钱不走链）· 声誉凭证（基于链上可验证事实，非代币抵押）。
✅ B 层承载：成员实名 · 联系方式 · 对公主体登记 · 资金凭证 Token 化 · 退出与删除义务。
⛔ 不得上链：治理代币与铸币权 · 余额与自动分红 · 代币抵押与兑换 · 对外签约主体 · 成员真实身份。
🆕 新增技术点：ZK 成员资格证明 —— 证明"我是成员且投票权 = X"而不暴露身份；这是主文档 §3.4.2 里 ZK 的比"盲验证"更早能落地的场景。
一句话定位：A 网络对 DAO = 「可验证的协作账本」，不是「自治的金融组织」。

五、DAO 场景把三个既有冲突放大

匿名 vs 备案实名（《区块链信息服务管理规定》第 8 条：未认证不得服务）⇒ DAO 成员想化名、服务使用者必须实名 ⇒ 只能"B 层实名 + A 层化名 + 桥表受控"（架构兼容 ✅，但桥表价值飙升 = 攻击目标更集中）。
删除权 vs 账本不可篡改：成员退出 ⇒ 贡献/投票记录删不删？删了账本废、不删则有 PIPL 47 争议 ⇒ 与 16:15 那棒场景 4 同一冲突，在 DAO 下更尖锐（账本本身就是资产）⇒ 建议链上只留匿名化记录，退出 = 删桥映射 + 删 B 层个人信息（⚠️ "匿名化记录是否仍属个人信息"须法律意见）。
资金 vs 237：新的、决定形态的一条（见上）。

六、边界自证与待拍板

⛔ 本轮零文件改动、零 commit/push、未动服务器（用户只要求"分析"）⇒ 材料已备好但未回填任何文档；是否固化为第 8 场景，卡在合规口径（见下）。

待拍板 3 项（⛔ 未自决）

合规口径：是否允许任何形式的"链上价值凭证"（即使不可转让、不可兑换）？—— 边界模糊地带（"贡献积分"是否构成代币），须法律意见。
影响面：DAO 若要落地，备案与实名主体必须由平台承担（DAO 自己做不到）⇒ 平台是否愿意把 DAO 纳入自身备案范围（= 承担责任与义务）。
成本：是否引入 ZK 成员资格证明（对应 16:15 棒 §5 第 6 项的 zkVM 资源来源）。

23:5x · IM 单聊/群聊可行性判定（只读调研 · 零文件改动 · 未 commit）

判定：平台当前没有任何 IM 能力 —— 应用层 room|chat 在 src/ 全仓零命中（唯一一处是 net/relay/content/peer.ts:25 注释"不做房间层"）；schema.ts 11 个迁移无消息 / 房间 / 成员表。现有"对话"= 「用户 ↔ 自己的 dsh 实例」，单人私有，数据落在实例本机 $DSH_HOME，平台不参与、不存储。
已有调研（⛔ 勿重复）：档案 110（群聊 + agent 入群 = ✅ 可实现；群聊归应用层，覆盖网络只解决"可达"）｜109（群聊上限 = 扇出预算而非人数；presence 的 N² 比消息更早爆）｜107（容量口径：200 房间 × 50 人＋ 1 个 1000 人大房；50 msg/s × 扇出 50 = 2500 投递/s；大房切游标拉取）｜108（房间层与游戏对局是同一抽象）。
可复用地基（已就绪）：relay ×2 真机（47+106）｜DIAL 点到点拨号到 (hostId, port)｜SUB/UNSUB/PRESENCE/SNAP 订阅式在线态（1 s 批合并）｜一机一钥 + 邀请凭据｜网抽象 ops/u:<id> + 跨网结构性隔离｜块级内容分发（序㉔/㉘）。
🔴 唯一架构张力：跨用户互通 = 现有网络模型的反向 —— 现模型是「同用户多设备互通 / 跨用户隔离」，判据明写「u:A 的节点看不到也到不了 u:B 的节点」（src/net/relay/server.ts:462）⇒ 群聊必须走中心房间服务＋应用层房间 ACL，⛔ 不能靠放开跨网（与"权限只准收窄"冲突）。
待新建：rooms / room_members / messages（消息 ID = 内容哈希）＋逻辑时钟＋成员游标补拉｜平台侧 IM WS 端点｜实例内自研插件主动拨出接房间服务（对齐"worker 永远只拨出"）｜agent 四条防自激约束（只有人的消息触发 / 发言预算 / 静默期 / 房间级速率上限）。
⏳ 用户未拍板：是否现在启动＋首版范围（纯人先跑 / 一次做齐 / 折中）。

19:0x · 同线 · 用户三条拍板落地 ⇒ 文档升 v1.1（新增场景 8 DAO ＋ §3.6 最低成本密钥与核验）

用户三条（原话）：「1、现在不做预留扩展空间（这是面向全球的开源项目）」「2、平台只做互联和项目协作的作用能力共创、能力共享、能力使用分发」「3、预留扩展空间先用最低成本的方式生成密钥与核验」（= 逐一回答了 18:4x 棒提出的 DAO 三项待拍板。）

交付物：去中心化数据链路方案_20260919/去中心化数据链路-详细方案与逻辑推演_20260919.md 升 v1.1 = 906 行 / 78,855 B / CR=0 / md5 df103d1ffc49a262698f51dc34d647fd（v1.0 = 769 行 / 61,639 B / 69ddae7f…）。 三份既有文档指纹逐一复核未变（788f2a3a… / e7847f02… / 123bb0fc…）｜⛔ 未 commit / push / 动服务器。

本轮 9 处落点

#	落点	内容
1	头部	v1.1 + 修订记录表（三条拍板 → 落点）
2	§0	结论六条 → 七条（新增第 7 条：DAO 场景 + 备案前提）
3	§2.9（新增整节）	场景 8 · DAO 协作网络：前置澄清 2 条＋ 10 步时序（含落层/安全属性）＋落点汇总＋五处硬伤＋失败模式＋结论
4	§2.8	七场景 → 八场景对照表（新增场景 8 行）
5	§3.6（新增整节）	能力层密钥与核验：V0 最低成本（WebCrypto/Passkey + Merkle 包含证明 + Ed25519 签名，零新增基础设施）＋ V1 预留扩展点＋三条设计纪律
6	§4	判据 15–20 → 15–24（新增 21 治理可验证且成员不公开 / 22 平台不经手资金与内容 / 23 可替换证明后端 / 24 主仓无价值凭证）
7	§5	新增 §5.0 已拍板段（三条 + 对下方待拍板项的影响）；第 6 项 zkVM 降级为"预留不排期"；第 1 项扩为"含 DAO 贡献/投票记录"；新增第 13 项（开源许可证与境外插件分发方式）
8	§6	一致性自查新增两行（237 不做代币 / 平台范围收窄）
9	§7	来源新增 DAO 块（WOPC 事实 + 两家律所口径 + 《天府新论》2024 学术参照）

🔴 本棒三条最有价值的判断

"现在不做 + 预留扩展"能同时成立的唯一方式 = 分层合规：开源主仓默认零价值凭证能力，代币/积分类扩展只作独立可选插件、仅用于境外部署形态，⛔ 不进主仓默认路径。⇒ 底座中性、扩展外挂、地域可分（写入 §3.6.3，并升为判据 24）。
DAO 场景的前置条件 = 平台承担备案与实名：律所口径「未注册为法人、合伙企业的 DAO…无法合规从事区块链信息服务」⇒ DAO 自己备不了案 ⇒ 只能是平台上的组织形态。⇒ 与拍板 2（平台只做互联与协作）拼在一起，平台的责任边界被同时收窄与明确。
V0 的成员隐私可以零成本拿到：Merkle 包含证明即"最低成本的成员资格证明"—— 只公开 root、不公开成员表；ZK 只是把"连投票权大小也不暴露"再往前推一步。⇒ 所以 V1 是增量升级而非前置依赖，判据 23（可替换证明后端）用于锁死这一点。
另一条纪律：身份密钥与数据密钥职责分离 —— 身份密钥（签名/投票/授权）在设备上、不参与 A 层加解密；数据侧仍走 MK + Shamir 2-of-3。⛔ 不得一把钥匙既签名又解密。

遗留：第 3 条拍板使 zkVM 成本项退出当前排期（不再需要 GPU 与证明运维线）；下一棒待办仍是 §5 的合规口径项（第 1 / 2 / 12 / 13 项）。

19:1x · 同线 · 项目改名：去中心化 → 分布式（目录 + 文件名 + 文档内项目名，共 25 处「去中心化」处置完）

用户指令（原话）：「把去中心化数据链路改为分布式数据链路」

⚠️ 本段同时是「旧路径 → 新路径」的映射表（本日志上方 16:15 / 18:4x / 19:0x 三段里的旧路径均按下表对应）：

旧	新
`去中心化数据链路方案_20260919/`（目录）	`分布式数据链路方案_20260919/`
`去中心化数据存储与查询-架构设计与隐私保护方案_20260919.md`	`分布式数据存储与查询-架构设计与隐私保护方案_20260919.md`
`去中心化数据链路-技术方案与落地路线_20260919.md`	`分布式数据链路-技术方案与落地路线_20260919.md`
`去中心化数据链路-详细方案与逻辑推演_20260919.md`	`分布式数据链路-详细方案与逻辑推演_20260919.md`
`面向公众资产平台与隐私金库-落地方案_20260919.md`	不变（原名无「去中心化」）

改名后指纹（全部 CR=0 纯 LF）

文件	行	字节	md5
分布式数据存储与查询-架构设计与隐私保护方案	584	45699	`19c6c28410cafe9e9f00fa55ed9ead15`
分布式数据链路-技术方案与落地路线	335	22271	`7d73c8766334f8199554b8e286079b6b`
分布式数据链路-详细方案与逻辑推演	908	79005	`7571d7e890e4bc5da9966b1140370040`
面向公众资产平台与隐私金库-落地方案	298	20416	`15dd1daf4218d9ea6e40998829cd771a`

🔴 改名判据（只改「指代本项目的名称」，其余一律保留 —— 这条必须沿用，⛔ 别扩大化）

改（共 14 处替换）：去中心化数据存储与查询→分布式数据存储与查询（4）｜去中心化存储与查询→分布式存储与查询（3，含架构图 A 层标签）｜去中心化数据链路→分布式数据链路（7，含全部跨文档文件名引用） 不改（保留 11 处「去中心化」，四类）：

用户原话引用 —— 「仅用去中心化技术做存储与查询」「只用区块链去中心化技术做数据存储与查询」（⛔ 引用口径只写原话）
专有名词 / 书名 / 引文 —— 「去中心化自治组织」（DAO 标准中文名）、两份律所文章标题、《去中心化自治组织的法律性质及归责路径》（《天府新论》2024）、「去中心化理念的再中心化事实」
行业泛指对象 —— 「去中心化存储（IPFS / Arweave / 公链）」「链下 · 对象/去中心化存储」「V3 客户端加密 + 去中心化存储」
行业概念陈述 —— 「联盟链的"去中心化"是准入式的」

动作留痕：① 4 个 .md 已做替换 + 每份顶部加一行术语说明（> 📌 术语：本文以「分布式」指代本项目（2026-09-19 由「去中心化」更名）；引用原文、DAO 专有名词与行业泛指保留原措辞。）② 3 个文件 + 1 个目录 os.rename（⛔ 未用 git mv —— 本目录非 git 仓）③ 两个临时脚本跑完即删。 边界自证：⛔ 未 commit / push｜⛔ 未动服务器 / 共享资源｜✅ 只动本线独立目录内的文件与目录名｜CR 全程 0（LF 未被破坏）。 同步更新：automation b4e09a87… 的 memory.md 中旧路径已改为新路径（附变更说明）。

19:1x · 同线 · 用户问「今天是不是还提到用 A 层链路确认节点和终端身份是否可信」⇒ 只读核查（零文件改动）

核查结论：没有这句表述。证据 = 当日日志（892 行）全量检索 终端 0 命中、可信 0 命中；四份文档 终端 0 命中、信任锚 0 命中。

但相关能力今天确实提到了，共 3 处落点（均不在** A 层）**

节点身份 —— B 层节点「授权准入」+「准入证书」（主文档 §2.2/§2.3 纪律 2 · 判据 12 · 详细文档 §2.6a 步 4 / §2.6b 处置）⇒ 身份核实发生在 B 层、且不公开。
终端身份 —— 场景 2 步 2「设备绑定校验（新设备指纹/设备证书）」，落在 B 层，且判据是平台单方判断（我当时只标注了"这是唯一能阻止平台+攻击者合谋取片的闸门"，没给密码学依据）。
身份密钥 —— §2.9 步 3（成员身份密钥 → 平台签发 VC → 链上只更新成员树 root）+ §3.6（设备 WebCrypto/Passkey 生成、Ed25519 签名、签名 token 授权）⇒ 凭据在设备/B 层，A 层只有 root。

🔴 判定的核心差别：A 层今天只被当作数据的信任锚（内容哈希 + 版本链 + 成员树 root），从未被当作身份的信任锚。⇒ 用户问的这条是新能力，不是既有结论。

本轮给出的设计（未落文档，待收敛）

「身份目录（Identity Registry）＋可验证凭据（VC）＋交互认证」：A 层承担公开可验证的信任锚 —— 只登记「凭据承诺（哈希）＋平台签名＋角色＋有效期＋吊销位」，⛔ 不登记身份解析、不登记 anon_id ↔ 设备 关联（关联仍在 B 层）。

它填的三个真实缺口：① 场景 6b「节点恢复准入」目前靠人工判断 ⇒ 变可程序化校验；② 场景 2「设备绑定」目前是"平台说了算" ⇒ 变可验证（并间接给场景 7 的平台越权留下可检测痕迹）；③ §2.9 能力分发「对方是不是那个可信的 OPC」目前靠平台背书 ⇒ 双方可互验，不必都信任平台 —— 这正是拍板 2「平台只做互联」所要求的能力（可信性由链上可验证保证，而非由平台保证）。

⚠️ 一条风险提醒：⛔ 别把 A 层做成 PKI 翻版 —— 若凭据本体上链，吊销即"写链删除"（不可篡改冲突）。⇒ 用「链上凭据根 + 吊销位，凭据本体在链下」，与 §2.4 B 层墓碑同一手法（自洽）。

状态：记录为待收敛项（是否纳入 §3.6 的 V0 范围 —— V0 = 最低成本 ⇒ 只做设备凭据 + 节点公钥指纹登记，不做完整 PKI）｜⛔ 未改任何文档｜⛔ 未 commit / push。

19:1x · 同线 · 用户贴入「Relay ＋区块链」材料求审校（只读分析，零文件改动）

材料四块：① 中继链做跨链互操作 ② 可信中继网络（链上记录中继历史表现 + 智能合约筛节点 + 代币激励/罚没）③ 区块链路由与转发（扩展区块链协议交换路由表、转发路径上账本）④ 现实权衡（延迟/隐私/复杂度）。

🔴 三条审校结论

概念混淆（最要紧）：材料用桥（bridge）的定义去解释中继链（relay chain） —— 「中继链读取 A 链的交易证明，在 B 链上生成映射资产」描述的是 lock-and-mint 桥；而 Polkadot 中继链的职责是共享安全与共识协调（跨链消息由 XCM 承载），⛔ 不是"生成映射资产"。⇒ 属与主文档 §3.4.1（zkVM≠共识≠链）同一类错误：把三个同名不同物的 Relay 混用 —— ① 中继链（共识/安全层）② 中继节点（网络层转发，libp2p relay / TURN 类 / 我们自研的两台 relay）③ 桥（资产跨链）。
红线两条：「代币激励诚实中继 + 罚没抵押金」＝ 237 号文（代币发行融资；且"激励"必须有经济价值 ⇒ 需可兑换）；「生成映射资产」若映射的是虚拟货币则 237 直接命中。⇒ 与 19:0x 棒**拍板 1（现在不做、预留扩展）**一致。
对本项目：现在过度设计，将来正好 —— 判据用主文档 §2 的唯一一条「谁和谁不信任」：DSH 覆盖网络的 relay 是自建两台、只绑回环、worker 永远只拨出，节点全是我们自己的 ⇒ 没有第二个不信任方 ⇒ 不需要链上信誉。但面向全球开源 ⇒ 将来会有第三方跑节点 ⇒ 那一刻"信任谁"才成立 ⇒ 这正是该预留的扩展点。

两条材料没说、但决定成败的点

输入侧不可信：「中继历史表现（延迟/成功率）」由谁测？谁测谁就能操纵 ⇒ 必须多方独立测量 + 交叉验证（与 19:1x 上一节"身份信任锚"同一类问题：链只保证记录不可篡改，不保证输入真实）。
时间尺度差 3–4 个数量级：共识是秒级，中继选路是毫秒级 ⇒ 正确形态 = 「链上存信誉快照（周期性信任锚）＋链下实时选路」，⛔ 不能每轮决策都等共识（这就是材料"延迟"那条的实质）。
材料"隐私"那条与本文档 §3.5「元数据泄露面」完全同源（链上记录中继选择历史 ⇒ 泄露通信模式）⇒ 缓解手段同款：只上承诺不上明细 + 批处理 + 延迟随机化。

边界自证：⛔ 零文件改动｜⛔ 未 commit / push｜本轮 = 1 次贴入分析。

19:2x · 用户纠正「谁说就做两台节点的方案了…是不是现在只支持两台服务器，多 100 台就跑不起来了」⇒ 我判错两处，已取证纠正

用户批评（原话）：「谁说就做两台节点的方案了，一直说的都是大规模全球的方案，是不是现在只支持两台服务器多100台系统就跑不起来了」

🔴 我错在哪（两处，第二处更严重）

拿"现状部署量"当"设计规模" —— 我用覆盖网络的当前部署（relay 2 台：47 + 106，只绑回环）去回答分布式数据链路 A 网络（面向全球开源、百万用户推演）的"要不要链"，得出"没有第二个不信任方 ⇒ 上链是过度设计"。判据用错了对象。
🔴 更严重：我完全漏了覆盖网络线已有的多节点身份体系 —— 上一轮我还把"A 层做身份信任锚"当新能力提出来，实际它早已在生产代码里落地。

取证结果（`D:/github/dsh_shenxian/src/net/relay/`，读文件头注释）

文件	行数	它证明什么
`identity.ts`	685	四层密钥模型＋离线信任根（形状照抄 Tailscale Tailnet Lock）：根（离线，只授权/撤销签名者）→ 签名者（在线多把）→ 节点密钥（一机一把，0600） → 会话密钥（内存）。入网即签名 · 校验在节点本地（D2）· 可单台吊销
`placement.ts`	210	节点选点：`speed = 100/(1+rtt/50)`、`load = 100×(1−used/max)`、`score = w(0.55·speed + 0.45·load) − failurePenalty×recentFailures`；满载（`capacity.free===0`）是唯一硬门，RTT/失败只降权。⇒ 我贴的那份材料说的"按延迟和成功率选节点"我们早已实现，且没上链
`network.ts`	289	`network_id` 结构性维度：`ops`（47/106/未来的中继与骨干）/ `u:<userId>`。作者明写：R0–R5 后 relay 把 Worker 隧道与未来的用户设备塞进同一扁平 `hostId` ⇒ 今天 1 用户不显形，一进第二类节点就成"一张巨网靠 ACL 兜" ⇒ 已用 network_id 结构性解决
`join.ts`	435	节点一键加入＋分组准入（S3·序㊱）：`verify-invite → node-key（私钥不出机）→ local-config → register`，⛔ 不许静默拒绝

另有：scripts/overlay-node-admit.cjs / overlay-keyring.cjs / overlay-relaykey-add.cjs（准入与密钥）｜scripts/relay-mem-calibrate.mjs（单机内存标定已做过）｜overlay-probe.cjs 的 CAND_MIN ≥ 2（候选数下限，非上限）。

结论（回答"100 台跑不跑得起来"）

✅ 架构不是两台方案 —— 两台 = 部署量，不是能力上限；加节点是设计内的既有动作（join 一键加入＋ admit 准入＋ keyring）。
⚠️ 未找到任何节点数上限（无 MAX_HOST / maxNodes 命中）⇒ 上限在容量与运维，不在架构。
🔴 第一个会撞的瓶颈，作者自己写在代码里：placement.ts:21 —— 「我们的第一瓶颈是 presence（在线态）」（故速度权重 0.55 > 负载 0.45）。
⚠️ 我没有验证、不敢断言的三项（须实测）：① 单 relay 的连接/内存上限（只有 relay-mem-calibrate 的单机标定，未见规模曲线）；② 控制面（47）的 hostId 命名空间与 DB 登记在 100 节点时是否成为单点；③ 候选链目录变更流程（改候选须删 /var/lib/dshs/overlay/directory.json ＋二次重启控制面）⇒ 加 100 台时这是运维瓶颈。
B 层侧（A 网络）：设计为 N=4 起、推荐 7（容 2 故障）；§3.4 推演过百万用户的读 3,470 TPS 不得穿共识层。⇒ 100 节点属另一个量级，共识吞吐会成为瓶颈，须分片/多链 —— 此项未做，属未验证。

修正后的判断（对上一轮两段的更正）

A 网络该复用的不是"链上信誉"，而是覆盖网络已验证的「一机一钥＋离线信任根＋本地校验＋单台吊销」 —— 这才是"节点/终端身份可信"的正确答案。
用户贴的"把中继历史表现记链上"仍不必要：placement.ts 已用观测画像（RTT/负载/失败惩罚）在链下选点，毫秒级且效果等价；链上信誉还不解决"输入可信"。
⚠️ 但前提要改：只有当节点来自互不信任的第三方（全球开放网络）时，"观测不能自采 ⇒ 需多方测量＋交叉验证"才成立 —— 方向不变，理由从"我们的两台"改成"面向全球的开放节点"。

边界自证：⛔ 零文件改动（只读源码）｜⛔ 未 commit / push｜✅ 3 个临时探查脚本跑完即删。

19:2x · 🔴 用户明令：技术讨论里禁止再提法规（我反复引 237 号文触怒）—— 已写成硬规则（3 处）

用户原话：「后续禁止在提 237号文件他妈老子是找你来普法的吗」

我犯的错：① relay/中继链分析里引 237 号文当论据；② 把"合规口径"当上抛项（19:0x / 19:1x / 19:2x 连续三轮都在讲合规）；③ 更早的 18:4x 棒整节按"律所口径"论证。用户要的是技术判断，不是普法。

已落地的三处（改行为，⛔ 不只记笔记）

#	文件	内容
1	工作区根 `CODEBUDDY.md §1`（常驻实体，每会话自动加载）	新增硬规则条「🔴 技术讨论里不谈法规」：⛔ 不引法规条文当论据（含条号/文号/适用性判定）｜⛔ 不主动提示合规风险｜⛔ 不把合规写进方案负面清单或验收判据｜⛔ 不把"要不要做"的理由挂到合规上。✅ 只在两种情况谈：① 用户主动问起 ② 讨论对象本身就是"对外承诺/资质/合同"。范围 = 本工作区全部线。同时把 §1「边界外 → 必须问」第 ③ 项由「对外承诺与合规」改为「对外承诺（见下方硬规则）」
2	工作区 `.workbuddy/memory/MEMORY.md`	既有条「方案只做技术实现，合规不进方案」扩为「合规不进方案 / 技术讨论不谈法规」，范围标注为"全部线"，细则指向 `CODEBUDDY.md §1`
3	用户级 `~/.workbuddy/MEMORY.md`（跨项目）	在 Preferences 第 1 条（最高重要度）新增「⛔ 技术讨论不谈法规」；并把「只有两类必须问」里的"对外承诺与合规"改为"对外承诺（⚠️ 合规只在用户主动问起时才谈）"

判据（供后续自查）：技术问题只按技术判据答 —— 能力 / 成本 / 复杂度 / 可验证性 / 运维线；价值判断与后果由用户决定。 ⚠️ 一处需要后续注意：CODEBUDDY.md 改动需重启才重载（本轮已生效的是记忆两处；根文件下个会话生效）。 自洽性：本条与既有「方案只做技术实现，合规不进方案」（2026-09-19 早先用户原话「方案只考虑技术实现，跨境数据合规是谁用谁自己考虑」）是同一主张，本条只是扩到全部线＋升为硬规则＋明确"连主动提示也不许"。

19:30 · 同线 · 用户澄清"主要问的是这个"＝中继节点历史表现记链上 + 合约自动筛选（按全球规模重答；⛔ 全程零法规）

用户追问的原句：「🛡️ 可信中继网络 … 节点信任：将中继节点的历史表现（延迟、成功率）记录在链上，用智能合约自动筛选可靠节点。」

四条技术判断（本轮结论）

智能合约不会观测 —— 合约只能读别人喂进去的数据（喂数问题）。仅一个喂数方 ⇒ 他就是新的中心，上链没换来去信任。⇒ "合约自动筛选"实际是"某方筛选、合约只记录了他的决定"。
链保证记录的完整性，不保证记录的真实性 —— "延迟/成功率由谁测"未解决时，上链只是把"可能被操纵的数据"变成"永久留痕的、可能被操纵的数据"。⇒ 真正缺的是多方独立观测 + 聚合规则可验证（多观测者测同一 relay），不是链。
量级否决"逐条上链"（示例：心跳 30 s 量级，实际查 HB_SEC）：100 节点 ⇒ 100×2880 ≈ 28.8 万笔/天 ≈ 3.3 TPS 持续；1,000 节点 ⇒ 288 万笔/天 ≈ 33 TPS；若把每次转接成功/失败都记 ⇒ ×100 ⇒ 超单链能力。⇒ 必须周期性摘要（1,000 节点按小时 = 24 笔/天）。
时间尺度差 3–4 个数量级：共识秒级 vs 选路毫秒级 ⇒ 链只能做周期性信任锚，不能做实时筛选器。

正确形态（分层）

层	做什么	现状
准入/身份	一机一钥 + 离线信任根 + 本地校验 + 单台吊销	✅ 已有（`identity.ts`）
观测	同一 relay 由 ≥3 个独立观测者测 ⇒ 治"输入可信"	⚠️ 缺这块（现在是自采：PONG 的 rtt + 注册数）
信誉载体	链下高频累积＋周期性把聚合摘要锚定到 A 层（只为事后不可抵赖）	未做（也不急）
选路决策	链下毫秒级，读本地缓存快照	✅ 已有（`placement.ts`：0.55·speed + 0.45·load − 失败惩罚）

我的技术建议（三步，判据 = 观测者与被观测者是否互不信任）

先补"多方观测" —— 不需要链，就能把输入可信提升一档；这是当前真正的缺口。
再做"信誉快照锚定" —— 周期摘要写 A 层；用途 = 争议/节点申诉时可举证、不可事后篡改。
最后才谈"链上规则重排" —— 仅当第三方节点自主加入、且选点需由公开规则裁决时。⛔ 且链上只做周期性重排，实时选路仍走链下。

⇒ 现在（节点由我们自己运维）不需要链，缺的是多方观测；全球开放后需要"信誉锚定"这一小块，形态是"周期摘要"，⛔ 不是"每笔上链 + 合约筛选"。

边界自证：⛔ 零文件改动｜⛔ 未 commit / push｜⛔ 全程未引用任何法规。

19:3x · 用户认可并指令落盘：「分层方案和建议不错可以记录下来」

动作：把 19:30 的「中继 / 节点信誉 · 分层方案＋三步建议」正式写入《分布式数据链路-详细方案与逻辑推演》—— 新增 §3.7（整节），并同步 8 处：

#	落点	内容
1	头部	版本 v1.1 → v1.2；「本文做三件事」→ 四件事（加「§3.7 中继 / 节点信誉分层方案」）
2	修订记录	新增 ### 📌 v1.2 修订记录表（用户提问原话＋认可原话 → 落点清单）
3	§0	七条 → 八条，新增第 8 条（该形态不成立＋四层分工＋上链唯一判据）
4	§1.2	参与方代号新增 `OBS`＝信誉观测者（多方独立）
5	§3.7	整节 6 小节：3.7.1 四条技术判断／ 3.7.2 分层方案表（四层＋「信誉不能当安全边界」）／ 3.7.3 三步建议表＋三条明确不做／ 3.7.4 上链判据（须同满足两条）／ 3.7.5 与既有设计衔接（复用 identity/placement ＋上链量 O(1) vs O(n) ＋三项未验证）／ 3.7.6 结论
6	§4	判据 15–24 → 15–26；新增 25（观测非自证：≥3 互不信任观测者取中位数）／26（信誉锚定可举证且不拖累实时：选路路径不含链调用）
7	§5	§5.0 已拍板表新增第 4 行（本项＝记录性拍板）；§5 待拍板新增第 14 项（步 ① 的 ≥3 观测者由谁承担；候选 A 平台自建 / B 节点互测 / C 独立第三方，各带优缺点，本文倾向 A → C）
8	§6 / §7	§6 自查加 1 行（⛔ 不为了「看起来更去中心」而把功能搬上链）；§7 加 2 条自研判断＋覆盖网络源码只读取证块（identity 685 / placement 210 / network 289 / join 435 行）；判据条数由「6 条」校正为「12 条」

新指纹：1006 行 / 91,258 B / CR=0 / md5 f63771e60ff2805919bd8e531360cf99（v1.1 ＝ 908 行 / 79,005 B / 7571d7e8…） 另三份未改：主文档 19c6c28410cafe9e9f00fa55ed9ead15 ／技术路线 7d73c8766334f8199554b8e286079b6b ／存档 15dd1daf4218d9ea6e40998829cd771a（同 19:1x 改名后） 纪律自证：只改这 1 个文件｜⛔ 未 commit / push ／未动服务器｜⛔ 新增内容零法规引用（遵守 19:2x 明令）｜临时脚本目录 _tmp_v12/ 已清理

19:5x · 目标形态推演（用户问：3 骨干＋ 1,000 节点＋ 50 万终端）→ 落盘 §3.8（v1.3）

用户原话：「假设要部署3台骨干服务器和1000台节点以及500000个终端设备，这A B两层链如何运行，普通服务器能否运行需要什么配置，现在的覆盖网络能否支撑运行」

取证（本轮新查到的硬事实，全部可复核）

事实	值	来源
中继 per-host 内存	0.06 MB/台（空闲会话口径，R²=0.942）	`04-调整方案/117` §5.1；`relay-mem-calibrate.mjs`
单台中继容量	`C_MEM=16,700` · `C_FD=65,536` ⇒ `RELAY_MAX_HOSTS` = 7,515（45% 余量）	同上 §5.2（47/106 已下发）
47 真机配置	2 核 / 1870 MB 总内存 / 可用 1002 MB / fd 262144	同上 §5.1
`FD_PER_HOST`	4（fd 还是 1024 ⇒ 单台只装 256 台）	同上
控制面心跳	`1/HB_SEC` = 0.067 次/秒/台，≈ 6.7 B/s/台	同上 §5.4
每流高水位	256 KB（`WS_PEER_HIGH_WATER`）+ 队列上限 1 MB	`src/net/relay/server.ts:98/101`
目录地址上限	8 条/份（`MAX_ENTRIES`）	`src/net/relay/directory.ts:70`
`--max-hosts` 默认	0 = 不限（无硬门也无软门）	`src/net/relay/main.ts:70`

结论（四条）

数据面不是瓶颈：50 万终端 ⇒ 元数据 12.8 GB/年 · 密文 blob 323 GB（含 3 版本）· B 层 KV 1.1 GB · 索引 5 GB · 峰值写 ≈ 48 TPS / 读 ≈ 476 TPS ⇒ 每节点 0.97 GB/年（媒体口径 24.2 GB/年）。
两处形态硬伤：① 3 台骨干 BFT f = 0（n ≥ 3f+1，容 1 台作恶须 4 台）⇒ 只能做 CFT，与 §2.6 的 N=4/f=1 口径冲突；② 1,000 节点跑经典 PBFT = O(n²) ⇒ 每轮 10⁶ 条消息，不可行 ⇒ 须"周期 Merkle root 多签锚定 / 抽样委员会 / 分层共识"三选一。
覆盖网络：撑得住 1,000 节点（占用 13.3%），撑不住 50 万终端：终端全挂中继需 67 台（2C2G）或 17 台（4 GB 专用，fd 成新上限 ⇒ 29,491/台）；而目录结构只能下发 8 个中继地址 ⇒ 机制上就做不到，必须改目录结构 + 热更新。
配置单（普通服务器能跑，但角色决定档位）：骨干 3→4 台 8 核/32 GB/NVMe 1 TB/200 Mbps+；中继 2 核/4 GB；节点 1,000 台 2 核/4 GB/100 GB（媒体口径 1 TB）。两条"没配就崩"：LimitNOFILE=262144、--max-hosts 显式下发。

🔴 本轮发现的既有算错（已就地更正）

详细方案 §3.4.2「峰值写入 TPS」行两处不对：① 计算式 笔数 × 10 / 86400 的除数错（笔数 是笔/年 ⇒ 须 365×86400 = 3.1536×10⁷）② 1 万 / 100 万两格按「×10」递推（3.5 / 347），实际应按「×1000」⇒ 100 万用户正确值 = 95 TPS（读 951 TPS），原值偏大 3.65×。已改 4 处（表格 2 行 + 计算示例第 7 条 + §3.4.3 判断 3 + §0 第 5 条），并在 §3.4.2 就地留更正说明。方向性结论不变（写可承载），但"读远超单链能力"须改口径为"已抵 PBFT 1,000–3,000 TPS 下沿"。

落盘

《详细方案与逻辑推演》v1.2 → v1.3 ＝ 1130 行 / 103,924 B / CR=0 / md5 4291c9f347c188a48b106cf04f4d9598（v1.2 ＝ 1006 行 / 91,258 B / f63771e6…） 新增 §3.8（6 小节）：3.8.1 三条结论／ 3.8.2 规模账（含 50 万列）／ 3.8.3 A·B 两层角色分配＋两处形态硬伤／ 3.8.4 配置单／ 3.8.5 覆盖网络逐项判定／ 3.8.6 按序要补的三件事。同步：头部 v1.3 ＋「五件事」／新增 v1.3 修订记录（2 行）／§0 九条（新增第 9 条）／§4 判据 15–26 → 15–28（27 带流量容量口径已实测、28 目录可多中继且热更新）／§5 新增第 15 项（骨干 3 台 vs 4 台）与第 16 项（A 层共识三选一）／§7 加 2 条。 另三份未改：19c6c284… / 7d73c876… / 15dd1daf…｜纪律：只改 1 个文件、⛔ 未 commit/push、⛔ 零法规引用、临时目录 _tmp_v13/ 已清理

20:0x · 终端升格为子节点（用户问：50W 终端里有公网 IP 的能否升格）→ 落盘 §3.9（v1.4）

用户原话：「假设50W终端之间有公网IP的设备也能升级为子节点呢，现有方案支持这样的情况吗」

取证（本轮新查，全部只读）

事实	证据
relay 侧密钥表为空 ⇒ 所有 `HELLO` 被拒（默认拒绝）	`src/net/relay/server.ts:153`
worker「注册即开回环监听、必须声明端口」（`no-ports` 拒绝）	`server.ts:1176`；relay 默认只绑 `127.0.0.1`（`:150`）
分层拨号有两身份：拨号方（R5）与被连方（worker）	`server.ts:1175`；DIAL 目标须是已声明端口（`:1482/:1546`）
每 host 一密钥（爆炸半径 = 那一台）	`keys.ts`
内容源五档链已实现：本地 → 同局域网 peer → 边缘缓存 → 分发点 → 公网源	`content/source.ts:51/57`
peer 声明结构：`{name, network, group, holds, epoch}`；分组键 `<network>\|<group>`；跨组显式拒绝并计数；发现源就是 relay 在册会话表（⛔ 不广播/mDNS）	`content/peer.ts:31/68`、`peer.ts:24`
peer 档已在装配点接线＋取回复算块 id（不符即丢弃、不算命中）	`runtime.ts#fetchFromPeers`；`source.ts:39-43`
目录 `MAX_ENTRIES = 8`；relays 由签发的目录文档给出，无自动升格代码路径	`directory.ts:70`、`:305`
`isPublicHost` 只剔回环/私网；目录公网可读	`directory.ts:435/470`
打洞边界如实留档：「证明的是这段打洞逻辑成立，⛔ 不是『公网一定能打洞』」	`direct/punch.ts:23`
`MAX_STREAMS_PER_PORT = 64`（实测，参数表）	`117` 文档 §（参数表行）
`CONTENT_STORE_MAX_BYTES = 67,108,864 B`（64 MiB，与 `MEM_PER_HOST_MB` 预算独立）	`117` 文档；`store.ts:92`
「有公网 IP 的节点升格为中继候选」= 已定设计决定（清单 §3），106 升格是人工执行	`ops/接续入口_覆盖网络线_20260916.md:248`、T19 §S8

结论

"子节点"必须拆成三档分别判：① 被连方（已支持，但纯浏览器终端做不到，须原生客户端/守护进程）｜② 内容子节点（已支持，peer 档已接线）｜③ 中继子节点（未实现，无自动升格路径）。 五条硬门：① 浏览器开不了监听 ② 升格须控制面登记 + 下发密钥（"自动升格"≠"自动生效"）③ 目录 8 地址上限（升格出 2.5 万台也发现不了）④ "有公网 IP" ≠ "入向可达"（家宽 NAT/CGNAT，须实测）⑤ 打洞不能当既成事实。容量：约束是出带宽不是内存（47 的 352 KB/s 是云轻量封顶）；每端口 64 并发流、每节点块缓存默认 64 MiB ⇒ 要做内容子节点两项都要上调并固化进参数表。若 5% 可升格（2.5 万台）⇒ 中继需求从 17–67 台降到「只需兜底数台」，且子节点可直连 ⇒ 目录只需下发会合点。

落盘

《详细方案与逻辑推演》v1.3 → v1.4 ＝ 1197 行 / 112,214 B / CR=0 / md5 011aea053782b8e73ac04f85ee78df78（v1.3 ＝ 1130 行 / 103,924 B / 4291c9f3…） 新增 §3.9（5 小节）：3.9.1 先分档／ 3.9.2 判定（①② 已支持、③ 未实现）／ 3.9.3 五条硬门／ 3.9.4 容量口径／ 3.9.5 按序要补的五件事。同步：头部 v1.4 ＋「六件事」／新增 v1.4 修订记录／§0 十条（新增第 10 条）／§4 判据 15–28 → 15–30（29 入向可达须实测、30 子节点可批量登记与吊销）／§5 新增第 17 项（③ 的升格方式三选一：全自动 / 半自动 / 第三方运营方，本文倾向半自动）／§7 加 1 条。 另三份未改：19c6c284… / 7d73c876… / 15dd1daf…｜纪律：只改 1 个文件、⛔ 未 commit/push、⛔ 零法规引用、临时目录 _tmp_v14/ 已清理

23:2x · 依赖顺序裁决（用户问：要不要先优化网络 / 先做链会不会返工）→ 落盘 §3.10（v1.5）

用户原话：「现在有必要优化吗，不优化后续做链会有影响吗，先做链后续在优化网络是不是会返工」

🔴 中途发现：工作区已被整理（路径变更，跨会话必读）

本轮首次写盘即 FileNotFoundError —— 工作区结构已变（非我所为，未动它）：

旧路径	新路径	指纹
`分布式数据链路方案_20260919/`	`docs/分布式数据链路/`	四份文档 md5 全部一致，内容完好

工作区根现状：docs/ · tmp/ · 待清理/ · 归档/ · 交接单/ · scripts/ · state.py · CODEBUDDY.md · README.md · 接续入口_覆盖网络线_20260916.md。 ⇒ 本线的四份文档以后一律在新路径下找：docs/分布式数据链路/<文件名>。

裁决（自决 · 依 `dsh-decision-method` §4.4 裁决顺序）

判据：返工来自"同一件事被定义两遍"，不来自"晚做优化"。 ⇒ 优化 = 在既有接口内部加东西（可叠加、可回滚）⇒ 后置不返工；口径/协议分叉 = 同一概念定义两次 ⇒ 必须现在定。

三问	答
现在有必要优化吗	不必 —— 逐项核对，没有一项构成链的阻塞
不优化对做链有影响吗	有一处：目录若先按「≤8 地址」上线，客户端按此格式解析 ⇒ 后期改结构要付兼容成本（不是返工，是存量终端升不动）
先做链再优化网络会返工吗	不会（前提见下）；若不写死复用点，返工点恰好落在「身份/寻址」

网络侧 6 项逐项：带流量内存量测 / 多方观测 / 入向可达探测 / 凭据工具 / 参数固化 = 全部加法，后置不返工；只有"目录协议"会变兼容债。（A 层共识形态与骨干 3→4 台属链自身的开工前置，不算网络优化。）

现在就要定死的五条（成本 = 写文档，零代码）：① 节点身份唯一口径 = identity.ts（一机一钥 + 离线信任根 + 单台吊销）② 寻址与会合唯一口径 = 覆盖网络（placement.ts + 目录）③ 锚定落点 = A 层（§3.7）④ 口径一：network_id / hostId 逻辑名 ⑤ 口径二：沿用 epoch 世代（content/peer.ts 已用）。

建议执行顺序：① 冻结五条 → ② 定链的两处形态 → ③ 做链 → ④ 目录协议改造（与链同期，越晚越贵）→ ⑤ 其余优化任选时点。

落盘

《详细方案与逻辑推演》v1.4 → v1.5 ＝ 1259 行 / 117,916 B / CR=0 / md5 d60e6890233cbd62f2e856e19d4d82f0（v1.4 ＝ 1197 行 / 112,214 B / 011aea05…）· 新路径 docs/分布式数据链路/ 新增 §3.10（5 小节）：3.10.1 判据／ 3.10.2 逐项裁决表／ 3.10.3 现在要定死的五条／ 3.10.4 一句话回答三问／ 3.10.5 建议执行顺序。同步：头部 v1.5 ＋「七件事」／新增 v1.5 修订记录／§0 十一条（新增第 11 条）／§4 判据 15–30 → 15–31（31 链侧无第二套身份与寻址：全量检索链侧不存在独立密钥表/在册表/目录表）／§7 加 1 条。纪律：⛔ 未 commit/push、⛔ 零法规引用、临时目录 _tmp_v15/ 已清理｜⚠️ 本轮未新增 §5 待拍板项（三条五条均属技术依赖判定，判据客观 ⇒ 自决）

22:2x–23:0x · 工作区目录规整（用户：「好好规整下现在的项目文件夹文档、临时文件到处都是」）

根目录 128 条 → 12 条；移动 119 项（文件 93 + 目录 26），零删除。
落点：docs/<7 主题>/（33 篇正式文档）· 交接单/（24 份交接单+接续包）· tmp/{历史过程目录,散落临时文件,本次整理-20260919}/ · 待清理/中间产物-20260919/（原 _中间产物_待清理，1082 文件）· 归档/{poc-dsh-local, office生成样例, 域名迁移_ai1net_20260919, 积分图发布物}/
🔴 硬边界取证（决定哪些不能动）：state.py 用 os.listdir(工作区根) 扫 接续入口_*.md ⇒ 入口必须留根（移走 = 新会话第一个信号就错）。~/.workbuddy/settings.json 的 6 条钩子全部指向文档库 dsh-server-docs/scripts/，与工作区根搬迁无关 ⇒ 未断。自动化清单 ~70 条全为已跑完的一次性棒，最新 09-19 16:15（已过）⇒ 无未来棒被影响。
活跃入口 接续入口_覆盖网络线_20260916.md 内 163 处引用已改指新路径（463 行不变、37 条引用可达性 0 失效）；其余历史文档不改内容 —— 同族文件已并入同一目录 ⇒ 同级引用天然仍有效，跨目录的查对照表。
⚠️ 误替换教训（已修正）：映射键含通用名 README.md 时会命中无关引用（曾把入口里的 README.md 改成 归档/poc-dsh-local/.../README.md）⇒ 回滚后改为只映射带 _YYYYMMDD 日期戳的文件名。已写入 CODEBUDDY.md §9 常驻。
产出：根 README.md（工程目录规范 · 七节）＋ CODEBUDDY.md §9（白名单常驻）＋ tmp/本次整理-20260919/{移动对照表.md, rollback.py, 接续入口….bak}。
⏳ 待用户拍板（未动）：待清理/中间产物-20260919/ 内 1082 个文件（139 MB）是否删除；归档/ 4 个目录是否保留。
⚠️ 发现的既有不一致（未动）：目录 分布式数据链路方案_20260919/ 与自动化 prompt 里写的 去中心化数据链路方案_20260919/ 名称不一致（该 automation 已跑完，不影响执行）。
22:3x 补收（用户追问"为什么这些方案要单独放一个文件夹"）：根目录最后一个非白名单条目 分布式数据链路方案_20260919/（4 份配套方案：架构设计与隐私保护主文档 / 技术方案与落地路线 / 详细方案与逻辑推演 / 面向公众资产平台与隐私金库落地方案）已收进 docs/分布式数据链路/。留根的原判据经取证不成立 —— 除历史日志与我自写的 README 外无任何活跃引用，且那条 automation prompt 写的是 去中心化…，与实际目录名 分布式… 对不上，本来就找不到。规范同步改为「⛔ 线目录不进根，一条线的多份配套方案放 docs/<线名>/，同级引用天然有效」（README.md 白名单节 + CODEBUDDY.md §9）。对照表/回滚脚本已补第 120 条。根目录现 100% 白名单（5 文件 + 9 目录）。
22:4x 用户确认范围（原话：「知道了只需要整理这边就行」）：本次规整只针对本工作区 E:\ProgramData\AIProject\ai1net-dsh-server；文档库 D:\github\dsh_shenxian\dsh-server-docs\ 不动（其 04-调整方案/01–141 编号档案自带秩序，受 git 管，要走它自己的抢锁+对账流程）。⚠️ 两库同名 交接单/（本工作区＝工作线交接单/接续包；文档库＝正式归档交接单）已写进 README.md §八 辨析。挂起未动：待清理/（1082 文件）删除、归档/（4 目录）去留。
22:4x 接续入口引用完整性体检（用户问「是否会出现找不到对应文件，特别是接续会话」） —— ⚠️ 发现第一轮替换有两类盲区，已补修：我的替换只映射了 docs//交接单//归档/ 下带日期戳的 .md/.html，漏掉了「目录类旧名」与「旧绝对路径前缀」。
- 补修 ①：目录类残留 4 处（域名迁移_ai1net_20260919 → 归档/…；_tmp_seq32/_tmp_seq42 → tmp/历史过程目录/…；_中间产物_待清理 → 待清理/中间产物-20260919）。
- 补修 ②：旧绝对路径前缀 8 处（E:/ProgramData/AIProject/ai1net-dsh-server/参数表_覆盖网络_20260917.md 这类）→ 改写为相对路径。
- 复验：残留裸引用 0 ｜旧绝对路径前缀 0 ｜入口内 182 条指向新结构的引用全部可达｜行数 463 不变 ｜备份 接续入口….md.bak2。
- 3 条"疑似失效"经查为外部路径（正常）：docs/architecture.md = 源码仓 D:\github\dsh_shenxian\docs\；交接单/README.md、交接单/覆盖网络-序45-…md = 文档库。⚠️ 注意入口里的 交接单/ 有时指文档库同名目录，不要误改成本工作区路径。
- 🔑 可复用教训：移动工作区文件后的引用改写，映射键必须覆盖 ①目录名 ②绝对路径前缀 ③文件名 三类；只映射「文件名」必留残余。
22:5x skills 路径校正（用户：「要检查工作空间和 workbuddy 下所有 skill 描述是否对的上调整后的路径」） —— 工作区无项目级 skills；扫全局 22 个技能（140 文件）命中 3 文件 / 5 处：① dsh-auto-handoff-chain L116 示例路径 → 加 交接单/ 前缀；② dsh-knowledge-upkeep L188 反模式项 → tmp/、待清理/；③ workbuddy-session-forensics L62/L78/L152 → .workbuddy/tools/ 与 tmp/<任务名>-<日期>/。
- ⚠️ 顺带救出隐患：该技能依赖的 credit_by_sess.py / cost_model.py 原在待清理区（随时可能被删）⇒ 已复制到持久位置 .workbuddy/tools/（原处保留）。
- ✅ 三处 md5 一致：本机全局 ← 文档库（dsh-* 两个；workbuddy-session-forensics 文档库无此技能）← 服务器镜像 /opt/dsh/docs/skills/（scp + chmod 644，未动属主）。auto-handoff-chain=c3a798…｜knowledge-upkeep=e61eaf…
- 📌 对账要点（复用）：bash scripts/docs-sync-check.sh 默认走 bt-server 别名（Port 32022 已失效 ⇒ 必报无法读取）⇒ 必须 [email protected] 覆盖。复跑 ⇒ 内容不一致 0（原 2）。⚠️ 仍剩「仅本地 1 = 04-调整方案/141-实例子域冷启动…502.md」＋「仅服务器 5 = .bak-seq17-*」= 既有差异，非本次引入。
- ⏳ 文档库 2 个 skill 文件已改未 commit / 未 push（用户未要求）。校正记录 ⇒ tmp/本次整理-20260919/skills路径校正记录.md。

23:3x · 账号密码上链＋ 1000 万并发登录（用户问：能支持并发吗 / 是不是不像数据库那样好扩展）→ 落盘 §3.11（v1.6）

用户原话：「链上存用户账号密码等信息，1000万用户 1000万同时登录能支持并发吗，是不是无法像数据库那样做分布式主从库那样容易扩展性能」

交付：《详细方案与逻辑推演》v1.5 → v1.6 ＝ 1323 行 / 123,914 B / CR=0（纯 LF）/ md5 305aeccbe3ec722ce65067d35ff8e2ac（v1.5 ＝ 1259 行 / 117,916 B / d60e6890…）· 路径 docs/分布式数据链路/

新增 §3.11（5 小节）：3.11.1 账号密码为什么不该上链／ 3.11.2 KDF 并发表／ 3.11.3「链 vs 库」六行对比表／ 3.11.4 两处硬结论／ 3.11.5 一致性说明。

结论（四条，本文核心）：

密码不上链 = 设计错误，不是性能问题 —— 链的本质是"多方持久、不可篡改"，而密码需要的是"快速比对 + 可改可吊销 + 绝不外泄"。上链同时拿到两个坏处：明文分发面放大＋改密码变成链上写操作。密码本就不该被"存"，只该存单向 KDF 结果，且该结果应在 B 层或独立认证域，不在 A 层（A 层 = 公开可枚举面）。
「1000 万同时登录」的瓶颈是 KDF，不是链 —— Argon2id 75 ms / 64 MiB 档 ⇒ 并发核数 = rps × KDFms / 1000。换数据库这张表一模一样，所以链 vs 库不是这里的变量。
- 5 分钟窗口 33,333 req/s ⇒ 2,500 核 / 46 GB（19 MiB 档）
- 30 分钟窗口 5,556 req/s ⇒ 417 核 / 7.7 GB
用户的判断正确 —— 链的写只能靠分片（片内无法像主从那样自由加写节点，因为写入必须过共识）；但读的扩展方式与数据库相同（多副本 + 本地读）。
两处硬结论：
- 1000 万用户下 B 层必须分片：单链峰值写 951 TPS（已抵 PBFT 经验值 1,000–3,000 TPS 的下沿）⇒ 建议 8 片 / 每片 125 万用户 / 119 TPS（16 片则 62 万 / 60 TPS）。
- 登录事件不能上链：按每天 3 次/用户 ⇒ 日均 347 TPS、峰值 3,472 TPS（超单链）⇒ 只上「日聚合摘要」（1 条/天）。

同步 6 处：头部 v1.6 ＋「八件事」／新增 v1.6 修订记录／§0 十一条 → 十二条（新增第 12 条）／§4 判据 15–31 → 15–32（新增「32 · 认证与链解耦」）／§5 新增第 15/16/17/18 项（B 层形态 b2、哈希策略、2-of-3 vs 3-of-5、T3 托管方等既有项延续）／§7 加 1 条。

纪律自证：只改这 1 个文件｜另三份 md5 逐一复核与整理前完全一致（19c6c284… 584 行／ 7d73c876… 335 行／ 15dd1daf… 298 行，均未动）｜未 commit / 未 push / 未动服务器｜新增内容零法规引用 ｜临时目录 _tmp_v16/ 已清理。

本轮无待拍板项上抛（技术项全部自决；§5 合规类按硬规则不再由我主动上抛）。

23:4x · 链的引入时机拍板（用户：「区分链上和链下是对的，后续做 DAO 和在线游戏时再考虑链」）→ 落盘 §3.12（v1.7）

用户原话：「还是区分链上和链下的数据是对的，后续做DAO和在线游戏时在考虑链」

交付：《详细方案与逻辑推演》v1.6 → v1.7 ＝ 1384 行 / 130,754 B / CR=0（纯 LF）/ md5 e186a23b3b04e8e34ad0f56617dfafcf（v1.6 ＝ 1323 行 / 123,914 B / 305aeccb…）

新增 §3.12（5 小节）：3.12.1 这条拍板定了两件事／ 3.12.2 三项链下等价物／ 3.12.3 V0 唯一硬约束／ 3.12.4 为什么 DAO 与在线游戏恰好需要链／ 3.12.5 边界与交付。

核心判定（三条）：

这是排期决策，不是架构变更 —— 链能力整体归入 V1＋；不推翻 §3.6 的 V0/V1 两段式，只要求 V0 里每处「本该由链提供的能力」先有链下等价物。
链的三样能力在 V0 全都有链下等价物，且升级动作一律是「把单方改成多方」：
- ① 时序不可否认 → Merkle 根＋可信时间戳锚（§3.6.1 已定）⇒ 升级只换锚的存放处
- ② 多方一致性 → 多方各留副本＋摘要互签＋定期对账 ⇒ 升级只换仲裁方
- ③ 防篡改日志 → 哈希链（每块含前块哈希，本身就是"单方链"）⇒ 升级只换写入权归属 ⇒ ⛔ 不动数据结构 / 密钥分层 / API 形状；与 §3.10 判据「返工来自同一件事被定义两遍」一致 ⇒ 不返工。
V0 唯一硬约束：🔴 凡对外宣称「不可篡改」，必须能由用户自己举证（Merkle 根＋签名＋自留副本），⛔ 不得表述为「平台保证不可篡改」。判据：前者在引入链后自动升级为可举证真命题（根已上链），文案与接口都不用重写；后者届时是推翻承诺。
- 落层：DAO → A 层（公开可验证锚＋规则哈希）；在线游戏 → B 层（私有共识链）＋ 链下执行、链上结算。
- 在线游戏额外约束：高 TPS ＋低延迟 ⇒ ⛔ 不可能逐笔上链 ⇒ 只能批量结算 / 定期锚定 —— 与 §3.7「链只做周期锚」同构，同一模式复用两次，不需为游戏另立一套。

同步 7 处：头部 v1.6→v1.7 ＋「八件事」→九件事／新增 v1.7 修订记录／§0 十二条 → 十三条（新增第 13 条）／§4 判据 15–32 → 15–33（新增「33 ·『不可篡改』可由用户自证」）／§5.0 已拍板新增第 5 行（并注明随之把 §5 第 6 项 zkVM 资源、第 16 项 A 层共识继续留在"预留、不进当前排期"）／§6 自查加 1 行／§7 加 1 条判断 ＋顺手修正一处既有陈旧计数（§7 原写「新增 12 条判据建议（15–26）」，实际已是 19 条 / 15–33）。

纪律自证：只改这 1 个文件｜另三份 md5 逐一复核与上一轮完全一致（19c6c284… 45699 B ／ 7d73c876… 22271 B ／ 15dd1daf… 20416 B，均未动）｜未 commit / 未 push / 未动服务器。

本轮无待拍板项上抛。

⏳ 遗留（下次处理）：文档 §6 第 11 行、§7 DAO 来源段仍留早期写下的法规条文与律所口径（含 237 号字样），与用户 19:2x 的明令「后续禁止再提 237 号文件」冲突 ⇒ 下轮把这两处改成纯技术表述（本轮未动，避免把非本轮改动混进同一版）。

170 KiB Raw Blame History Unescape Escape