Board Private / Config / Execution

best-minds-board-private：
当前配置逻辑与执行逻辑

这条链路本质上是在做三件事：先把 canonical root 当本地全量档案，再把一份 脱敏后的 staging 交给旧版发布器，最后只把少量公开产物与日志回写到 canonical root。当前实现里最关键的判断有两个：一是 root 解析仍会回落到 BEST_MINDS_BOARD_ROOT；二是私有 wrapper 会先决定默认值，再把它们映射进 legacy rebuild / publish，而不是让旧链路按自己的默认值跑。

Root Priority

--root → BEST_MINDS_BOARD_PRIVATE_ROOT → BEST_MINDS_BOARD_ROOT → 默认 board root

Canonical Lock

默认只允许 canonical root；要绕过，必须显式设 BEST_MINDS_BOARD_PRIVATE_ALLOW_NON_CANONICAL_ROOT=1

Private Defaults

inject=minimal、enforceEnding=0、freezeLegacy=1、relatedRuntime=1、topicHistoryAutoCreate=0

Backup Defaults

backupGit / backupPush / backupStrict 默认都开；真正备份发生在发布成功并回写公开产物之后

谁最懂这个问题

Gregor Hohpe

看边界。这里最重要的不是“发不发出去”，而是 canonical root、staging、legacy publish 三个边界是不是清晰。当前实现是清晰的：全量档案留本地，外发只经脱敏 staging。

Michael Nygard

看默认值与门禁。泄露扫描默认阻断、canonical root 默认锁死、backup strict 默认开启，这些都是典型的 safe-by-default 操作性设计。

Charity Majors

看可观测性。private-publish/latest.json、history、同步回写的 deploy.json、最终输出的 URL 与 commit，让一次发布不是“黑盒成功”，而是可复盘事件。

配置逻辑

Resolution Skeleton

root = --root
    ?? BEST_MINDS_BOARD_PRIVATE_ROOT
    ?? BEST_MINDS_BOARD_ROOT
    ?? ~/Desktop/MINE/docs/best-minds-board

if root != PRIVATE_CANONICAL_ROOT
  and ALLOW_NON_CANONICAL_ROOT != 1:
  fail

backupGit    = cli ?? env ?? true
backupPush   = cli ?? env ?? true
backupStrict = cli ?? env ?? true

injectMode   = PRIVATE_INJECT_MODE ?? "minimal"
enforce      = PRIVATE_ENFORCE_ENDING ?? false
if enforce and injectMode != "full":
  injectMode = "full"

What Actually Decides Behavior

私有 wrapper 自己不直接读取 board.config.json 来决定这些私有默认值。
board.config.json 主要仍由 legacy publish / rebuild 在自己的解析逻辑里消费。
但 private wrapper 会把自己的结果映射成 BEST_MINDS_BOARD_* 和 BEST_MINDS_BOARD_PUBLISH_* 传下去，所以旧链路的“默认 full + enforce”被覆盖掉了。
换句话说：行为默认值先由 private wrapper 决定，旧链路更多是在执行。

现在最容易被误读的一点是 skill 文档强调“私有链路只读 BEST_MINDS_BOARD_PRIVATE_*”，但当前实现对 root 仍保留了 BEST_MINDS_BOARD_ROOT 回退。这意味着“配置隔离”在路径解析上不是完全绝对的。

配置时序图

当前实现的配置优先级不是“所有私有变量独立闭环”，而是 root 解析仍允许回落到 BEST_MINDS_BOARD_ROOT；真正的行为默认值则由 private wrapper 先定，再映射进 legacy 脚本。

执行逻辑

1. Canonical First

先校验 legacy 脚本存在，再按私有默认值重建 canonical root。这里生成的是本地完整档案，而不是对外发布版。

2. Stage Then Sanitize

真正对外走的是临时 staging：复制 canonical root，加载 private.redact.json 与 private.redact.local.json，对文本和 JSON 做脱敏。

3. Gate Before Deploy

在 staging 上补 closing、跑 ending check、跑 leak scan。默认 leak findings 会阻断部署；ending gate 只有在 enforceEnding=1 时才真正阻断。

4. Legacy Publish As Engine

调用旧版 publish-board.mjs 时传入的是脱敏 staging，并用环境变量把 private defaults 映射进去。旧脚本负责 slim staging、Vercel 部署和 alias 解析。

5. Sync Back The Minimum

成功后只把少量公开产物同步回 canonical root，例如 index.html、data/board.json、deploy.json，而不是把整个发布 staging 回写。

6. Backup Happens Late

git backup 发生在发布成功且同步完成之后；如果前面的 gate 失败，通常只会写私有日志，并不会产生一次“完整备份提交”。

执行时序图

核心边界是：canonical root 保留全量本地归档；只把脱敏后的 staging 交给 legacy publish；发布后只回写少量公开产物与日志。

当前最值得注意的 4 个点

Default Drift

private wrapper 的默认值和 legacy publish 的默认值不同。前者主张 minimal + enforce=0，后者天然偏向 full + enforce=1。当前实现通过显式 env 映射消掉了这类漂移。

Config Isolation Is Partial

“只读私有环境变量”并不完全成立，因为 root 解析仍回退到 BEST_MINDS_BOARD_ROOT。如果后续要做更强隔离，这里是第一处该收口的位置。

Archive vs Publish

这套设计真正保护的是“原始资料不直接上公网”。要理解它，必须分清 canonical root 是档案层，staging 是发布层，legacy publish 是分发引擎。

Observability Is Real

不是只有 URL。成功和失败都会在 private-publish/latest.json 留下一次可追踪记录；这是当前链路最有工程价值的一部分。

一句话结论

Conclusion

现在的 best-minds-board-private 不是“重写一套发布器”，而是“用私有 wrapper 接管默认值、门禁和脱敏，再借 legacy publish 完成分发”。

分析基于当前本地脚本实现：publish-private-board.mjs 与 publish-board.mjs。这份报告描述的是 2026-03-15 当前行为，而不是 skill 文档的理想语义。

best-minds-board-private：当前配置逻辑与执行逻辑