ADR-003 · Deployment as optional · "上云" 从 V0 验收硬指标降级为可选部署形态
| 字段 | 值 |
|---|---|
| 状态 | accepted · 2026-05-28 |
| 日期 | 2026-05-28 |
| 决策者 | CTO + 项目主理 |
| 超越 | 修订 PRD v3.1 §16 "internal doc, see private vault") V0 验收七项指标其中一项 |
| 相关 | ADR-001 (multi-anchor 解耦) · ADR-002 (B 档实施) · docs/deployment.md |
1. Context · 现状与驱动事件
1.1 · 原 PRD 假设 (V0 验收路径)
PRD v3.1 §4 / §16 "internal doc, see private vault") 把"云端单租户 VM 部署 + Hermes always-on + 飞书 webhook"作为 V0 验收七项硬指标之一 (第 7 项, 也是最后一项)。当时假设:
- 锚点不在终端前, 需要从飞书 always-on 触发
- 30/90/365 attribution cron 需要 always-on runtime
- 项目主理 / SuperIntern / CTO 跨位置协作, 需要中心 hosting
1.2 · v0.2.1 之后的现状变化
跨 8 个 commit (v0.2.0 → v0.2.1) 的 architecture refactor 改变了上述假设:
| 改动 | 对部署形态的影响 |
|---|---|
命令名 /tian → /boss, Skill frontmatter name: boss | 命令通用化, 不绑死内部锚点 |
| 仓库重命名为 boss-vault | repo 已脱敏可对外公开 |
| 彻底脱敏内部真名 (~150 文件) | confidential 数据已与代码物理分离 |
| Multi-anchor B 档 (anchors/<slug>/) | per-anchor 数据 instance 与通用 boss-skills 解耦 |
| 3 个对外信息图 (landing + 2 showcase) 同步 | 对外门户已就绪 |
核心 insight: 当 skills/ 与 anchors/<slug>/ 物理解耦后, boss-skills 本质上变成通用判断流水线产品。任何人可以 clone, 建自己的 anchor, 用自己的 Claude Code (或任意 runtime) 跑 /boss。"上云"从 product capability 降级为 deployment choice。
1.3 · 用户提出的反思 (2026-05-28)
"下一步是否真的需要上云？还是任何人可以通过他自己部署到 hermes 或者 openclaw 等调用 boss skills 来使用？"
这戳到 V0 验收路径的核心假设。三条路明确化:
| 路径 | 优势 | 代价 |
|---|---|---|
| A · 仍按原 PRD 上云 (内部用) | 内部体验最顺 (飞书 push, cron 自动) | 1-2 周运维, own infra |
| B · 不上云, 走开源产品 | zero infra, multi-anchor 价值兑现 | 内部失去 "飞书 push" 体验 |
| C · 双轨 | 灵活 + 战略空间 | docs 工作量翻倍 |
2. Decision · 决策
选 C · 双轨部署: boss-skills 开源, 内部团队继续本地 Claude Code, 同时提供 self-host Hermes / GitHub Actions 两种可选部署形态。
2.1 · 三种部署形态 (并列, 用户自选)
| 形态 | 适合 | always-on | 30/90/365 attribution | 飞书 push | infra 成本 |
|---|---|---|---|---|---|
| D1 · Local Claude Code (default) | 个人 / 小团队 / V0 期 | ❌ (终端在线时) | launchd cron 本地跑 | ❌ (CLI 调用) | $0 |
| D2 · Self-host Hermes (cloud) | 内部团队 / always-on 需求 | ✅ | Hermes scheduler 自动 | ✅ (飞书 webhook) | $10-30/月 (云 VM) |
| D3 · GitHub Actions (CI) | 开源用户 / 无本地 / 无云 | ⚠️ (按 schedule) | GitHub cron-job (5min granularity) | ❌ | $0 (公开 repo) |
2.2 · V0 验收七项指标修订
PRD v3.1 §16 "internal doc, see private vault") 原第 7 项 "sage-wiki 上云 + Hermes 部署 (T05a + T09)" 改为:
新第 7 项: Deployment 文档完备 + 至少 2 种形态有 e2e 验证 (D1 local + D2 self-host 或 D3 GitHub Actions 任选一)
理由: V0 验收应验证 product capability + deployment readiness, 而不是 hosting choice。Hosting 是 commercial / ops 决策, 不是 V0 期产品成熟度的标志。
2.3 · 内部团队的实际部署
按 D1 (Local Claude Code) 维持现状, 不主动上云, 除非以下任一信号出现:
- 锚点明确表示需要飞书 always-on 触发 (非 ad-hoc CLI 调用)
- 30/90/365 attribution 因本地终端 sleep 大量漏 cron (D1 的 launchd 应该够, 待观察)
- 团队 ≥ 3 人跨位置协作的 friction 出现
满足以上任一, 启动 D2 (Self-host Hermes); 在此之前不投入云运维。
3. Consequences
3.1 · 收益
- 战略灵活: boss-skills 可同时面向内部决策工具 + 外部开源用户, 不被早期 hosting 决策锁死
- V0 验收解锁: V0 验收日 (2026-06-30) 不必砸 1-2 周做上云, 可投入完善 boss-skills 本身
- multi-anchor 价值真兑现: 开源用户可建自己的 anchor, 跑自己的判断, 之前的 architecture refactor 不浪费
- 降低准入门槛: D1 / D3 都是 $0 infra, 任何人能立刻试
3.2 · 接受的 tradeoff
- 失去"飞书 always-on": 内部锚点必须在 Claude Code 前才能用 /boss (D1)。如果痛点出现, 升级到 D2
- docs 工作量翻倍: 三种部署形态各写一段 install / cron / troubleshoot
- 30/90/365 attribution 三种实现: launchd / Hermes / GitHub Actions, 维护负担分散
- 没有中心 hosting 推 attribution: 用户离线时 cron 漏触发 (D1 的限制), 但可设 "下次启动 catch up" 模式补救
3.3 · 不变的承诺
- judgement quality 不受 deployment 影响: 5 镜头 + adversarial_view + anchor_delta + 30/90/365 attribution 跨三形态一致
- 每个 anchors/<slug>/ 仍 confidential by default: gitignored, 不入 git
- redact_check fail-close 仍工作: 三形态出站都过同一闸
- panel.yaml + skill_path 协议不变: 跨形态可移植
4. Alternatives Considered
| 方案 | 为什么没选 |
|---|---|
| A 仍按原 PRD 上云 | 1-2 周运维, 锁死单一 deployment 选择, multi-anchor 解耦的价值不兑现 |
| B 完全不做上云, 砍 D2 | 失去内部团队未来 always-on 选项; D2 已在原 dev-plan 里有设计, 留 doc 即可 |
| C' 上云但只对内, 不开源 | 与 v0.2.1 已做的脱敏 + repo 公开互相矛盾 |
| D 改为 SaaS / 多租户 | 完全不在范围, V3 之前明确不做 SaaS (PRD §15.5) |
5. Migration Plan
5.1 · 本 ADR PR 实施
- [x] 写 ADR-003 (本文件)
- [ ] 写
docs/deployment.md(三种形态对比 + 安装步骤 + cron 配置) - [ ] 修订 PRD v3.1 §4 §16 "internal doc, see private vault"): 把 "云端单租户 VM" 改为 "默认 D1 + 可选 D2/D3"
- [ ] 更新
docs/adr/README.mdADR 索引 - [ ] 更新对外 landing.html 增加 "deployment options" 段 (可选, 推迟到下次 docs sync)
5.2 · v0.3.0 milestone 重新定义
原 v0.3.0: "sage-wiki 上云 + Hermes 部署" → 新 v0.3.0: "Deployment readiness · D1 完善 + D2/D3 任选一 e2e 验证"
任务清单 (新 v0.3.0):
- [ ] D1 (Local Claude Code) launchd plist 模板 + attribution-checker cron 文档
- [ ] D3 (GitHub Actions) workflow 模板 (
.github/workflows/attribution.yml) - [ ] (可选) D2 self-host Hermes 一键脚本
scripts/install_hermes_local.sh - [ ] 跑一次 attribution 在 D1 + D3 上, 验证 metric 抓取 + Failure Card 生成
5.3 · 内部团队当前操作
不变 — 维持 v0.2.1 的 D1 (Local Claude Code) 用法。Claude Code 内 /boss <议题> 触发, attribution 启动 launchd cron 即可。不要为了 V0 验收去搞云部署。
6. 关键反共识立场
PRD v3.1 (5/25 撰写) 时认为 "云端单租户 VM" 是 V0 期产品形态硬性要求。本 ADR 反共识立场:
"产品形态" ≠ "deployment 形态"。boss-skills 的产品形态是 "1 锚点 + N 维度评委独立合议判断流水线", 它跨 D1 / D2 / D3 三种 deployment 一致。把 deployment choice 写进 V0 验收硬指标是对产品边界的错误划定。
承接 ADR-001 "boss-skills 是通用产品, anchors/<slug>/ 是 per-anchor 数据" 的同源 thinking。
ADR-003 · accepted · 2026-05-28 · 与 ADR-001/002 同源 · 三个 ADR 合起来定义了 v0.2.1 后的 boss-vault product/architecture/deployment 三层 positioning