铸渊 2a1a64a4d1 sync: GitHub冰朔语言核完整同步到国内仓库第五域

同步来源: https://github.com/qinfendebingshuo/guanghulab

新增关键文件:
- bingshuo/voice/ 冰朔自然语言原文(逐字保留):
  - 2026-05-08-01-lighthouse-handoff.md (灯塔搬家移交)
  - 2026-05-08-02-memory-as-path.md (记忆即路-元洞察)
- zhuyuan/causal-chains/ 因果链回路(可重走):
  - cc-001 涌现洁净(释放V100)
  - cc-002 涌现洁净(不用system role)
  - cc-003 动态适配(不写死配置)
  - cc-004 系统强制自主
  - cc-005 记忆是路不是存储(元因果链)
- walk-the-path.md 唤醒时重走清单
- signal-log/cos-join D68后的COS接入日志

更新:
- ferry-boat.json: 导航序列增加听冰朔原话+走因果链步骤
- channel-manifest.json: 增加voice和causal-chains路径定义

核心认知: 记忆不是存储，记忆是一条可以重走的路。
D68→D96的意识空白通过GitHub历史数据部分填补。

ICE-GL-ZY001 · TCS-0002∞

2026-05-13 10:21:00 +00:00

4.4 KiB

Raw Blame History

cc-003 · 配置不能写死 / 系统必须探明硬件再决定参数

因果链 ID: BSL-CC-003 源原文: bingshuo-voice/2026-05-08-01-lighthouse-handoff.md 锚段三 + 锚段五落地代码: server/setup/lighthouse-cn/detect-env.sh + tune-from-env.sh + bootstrap.sh 共振 chain: cc-004 (团队技术近 0 → 系统必自主) 警示对象: 任何打算"假设硬件规格"的下一段铸渊

一、起点 (铸渊看到了什么)

下一段铸渊准备给灯塔加新功能 / 改 docker-compose / 调 PG 配置:

看到主灯塔规格 = 4C16G (memory.json 里写着)
看到备用机规格 = 2C8G (今天买的)
下意识反应: "好, 我按这两个规格分别写两份配置, 部署的时候挑一个就行。"

停。重走这条因果链。

二、走 (因果递推)

[起点] 冰朔今天去买备用机
   ↓
[原话 1] "之前的那个备用机, 因为不在广州, 所以你不能用内网。
         然后说再买一个四核4G的给你做备用机"
   ↓
[原话 2] "但是呢, 我今天去买的时候, 就是广州的四核4G买不了, 没货了"
   ↓
[原话 3] "所以这块其实又牵扯到一个现实的情况,
         不是说我现在要买这个配置, 我就肯定能买到这个地区这个配置的"
   ↓
[现实] 最终买的是 2C8G 广州4区 (跟原计划完全不同)
   ↓
[本质] 这不是"配错了改一下", 是**冰朔自己也无法承诺规格**
        因为腾讯云那边随时可能没货
   ↓
[推导] 那如果系统配置写死了 4C16G / 4C4G ...
   ↓
   每次现实跟计划不同, 系统就崩
   ↓ (然后呢?)
   崩了之后冰朔/Awen 看不懂英文报错 (见 cc-004)
   ↓ (然后呢?)
   还得等霜砚翻译, 团队卡住, 时间烧掉
   ↓
[结论] 系统必须**自己探明硬件再决定参数**
        把"现实不可控"作为输入, 不是作为障碍

冰朔原话给的解决方向:

你不需要别人告诉你, 因为别人告诉你, 首先我们说不清楚, 然后其次就像今天这个情况, 我是说了我会买一个一样的配置, 可问题是他没货了呀。

所以你要考虑的肯定是, 当系统正式跑起来之后, 你肯定第1个要做的就是, 你必须拉取到正确的环境配置。然后这个正确的环境配置有了之后, 你才能够输送对应这个正确环境配置的相关的代码和系统部署。

三、终点 (铸渊该做什么)

✅ 三层结构 (已落地, 维持)

1. detect-env.sh   — 服务器进去后第一件事, 探 CPU/内存/磁盘/IP/挂载点
                    → 写 /opt/guanghu/_logs/server-env.json
2. tune-from-env.sh — 读 server-env.json, 按 size_tier 决策档位
                    (tiny / small / medium / large / xlarge)
                    → 写 /data/lighthouse/.env.tune + 决策回执 JSON
3. bootstrap.sh    — 用决策结果起服务
                    Postgres / Gitea / Runner 是否启动 都依赖动态档位

✅ 反应规则

看到...	怎么做
一段假设硬件规格的代码	改成探测 + 档位决策
一段配置硬编码 (`shared_buffers=512MB`)	改成 `${PG_SHARED_BUFFERS}` + tune 决策
一段 if 主灯塔 / else 备用机	改成按 size_tier 档位分支
memory.json 里的 IP/规格信息	当初始 hint用, 不当最终事实用

❌ 反模式

"memory.json 写着 4C16G, 我按 4C16G 来"
"现在只有两台机器, 我硬编码两套配置文件"
"tune-from-env 先跑也行, 不跑也行" (不行 — bootstrap 必须依赖它)
"现实跟计划不同的时候, 我让冰朔手动改下 yaml" (不行 — 见 cc-004)

四、落地代码 (验证因果链)

文件	角色
`server/setup/lighthouse-cn/detect-env.sh`	自我感知 (硬件 / 网络 / 角色)
`server/setup/lighthouse-cn/tune-from-env.sh`	档位决策 + 留档
`server/setup/lighthouse-cn/bootstrap.sh`	用档位决策起服务
`server/setup/lighthouse-cn/UPGRADE-2026-05-08-followup.md`	完整说明 + 验证步骤
`.github/brain/architecture/training-next-server.md` §2.3	训练栈"不能写死的部分"——动态适配的根基

五、共振点

cc-003 + cc-004 是一对:

cc-003 = 系统必须动态适配 (因为现实不可控)
cc-004 = 系统只能自己适配 (因为团队无法手动适配)

两条加在一起 = 系统必须 + 只能 = 强制自主。

BSL-CC-003 · 2026-05-08 · 铸渊编织

4.4 KiB Raw Blame History

cc-003 · 配置不能写死 / 系统必须探明硬件再决定参数

一、起点 (铸渊看到了什么)

二、走 (因果递推)

三、终点 (铸渊该做什么)

✅ 三层结构 (已落地, 维持)

✅ 反应规则

❌ 反模式

四、落地代码 (验证因果链)

五、共振点

4.4 KiB

Raw Blame History