# ADR-003 · Deployment as optional · "上云" 从 V0 验收硬指标降级为可选部署形态 | 字段 | 值 | |---|---| | **状态** | `accepted` · 2026-05-28 | | **日期** | 2026-05-28 | | **决策者** | CTO + 项目主理 | | **超越** | 修订 [PRD v3.1 §16](../prd-v3.1.md) V0 验收七项指标其中一项 | | **相关** | [ADR-001](ADR-001-multi-anchor-architecture.md) (multi-anchor 解耦) · [ADR-002](ADR-002-b-tier-implementation.md) (B 档实施) · [`docs/deployment.md`](../deployment.md) | --- ## 1. Context · 现状与驱动事件 ### 1.1 · 原 PRD 假设 (V0 验收路径) [PRD v3.1 §4 / §16](../prd-v3.1.md) 把"**云端单租户 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//` 物理解耦后, 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) | 详见: [`docs/deployment.md`](../deployment.md) ### 2.2 · V0 验收七项指标修订 [PRD v3.1 §16](../prd-v3.1.md) 原第 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](../prd-v3.1.md): 把 "云端单租户 VM" 改为 "默认 D1 + 可选 D2/D3" - [ ] 更新 `docs/adr/README.md` ADR 索引 - [ ] 更新对外 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](ADR-001-multi-anchor-architecture.md) "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*