借力現有服務的整合策略

這份文件定義 Bullinv Forge 如何利用既有 SaaS 與成熟工具，快速建立 AI-native 工作平台，同時避免被單一上游平台綁死。

核心判斷

你的想法是可行的，而且很合理。

如果某個上游服務已經把某一個垂直能力做到非常成熟，例如：

Linear: task management
Slack: 團隊通知與討論
GitHub: code、PR、issue、review
Notion: docs 與知識整理

那 Bullinv Forge 沒有必要從零重寫那些成熟能力。

更好的做法是：

先借用它們已經很強的能力
在上面疊加 agent orchestration、shared visibility、run trace、review flow、skill layer
把你的差異化放在 AI-native 工作系統，而不是重做 generic SaaS

為什麼這樣做是對的

1. 你可以快速得到成熟 UX

例如 Linear 的優勢不是只有 API，而是它整體產品已經很完整：

任務板
狀態流轉
手機 App
通知
指派
搜尋
歷史記錄

如果你直接借用 Linear 當 task system 的 upstream，你等於一開始就站在成熟 task management 能力上。

2. 你可以把精力放在真正差異化的地方

你真正要做強的不是：

再做一個 issue tracker
再做一個評論系統
再做一個手機任務 App

你真正要做的是：

agent runtime
task router
agent registry
run log
workflow / handoff
review / approval
skill 資產化

3. 你可以保留使用者既有習慣

很多團隊已經習慣：

用 Linear 管工作
用 GitHub 管 code
用 Slack 看通知

如果 Bullinv Forge 能直接接進這些工作流， adoption 會比強迫大家全部換系統更容易。

`Linear` 作為第一個上游很合理嗎

合理，而且很適合作為第一個整合目標。

你可以把 Linear 視為：

task system upstream
human-facing work board
issue lifecycle source

而 Bullinv Forge 自己負責：

task routing
agent assignment
run execution
status mirroring
blocker / summary / review augmentation

也就是說：

Linear 管通用任務管理， Bullinv Forge 管 AI-native 的執行與協作層。

建議的整合方式

不要直接把 `Linear` API 當成你的核心資料模型

這是最重要的原則。

錯誤做法：

你的內部 Task 直接等於 Linear Issue
你的 state machine 完全綁定 Linear 欄位
你的 agent 直接操作 Linear payload 結構

更好的做法：

Linear 是 upstream system
你內部有自己的 Task canonical model
Linear Issue 只是 ExternalTaskReference 之一

建議的設計方式

1. 建立內部 Canonical Task Model

例如你的內部 task 至少要有：

task_id
workspace_id
title
description
status
priority
owner
assignee_type
assignee_id
review_state
blocker_state
source_system
source_ref_id

這樣你的核心永遠依賴自己的 model，不依賴 Linear 的欄位命名。

2. 把 `Linear` 放進 Adapter Layer

建議做：

LinearAdapter
GitHubAdapter
SlackAdapter
NotionAdapter

讓這些平台都只是外部系統 adapter。

3. 做雙向同步，而不是單向依賴

你可以讓 Bullinv Forge：

從 Linear 拉任務進來
在內部建立 canonical task
agent 執行後回寫 comment / status / assignee / blocker

這樣使用者仍可在 Linear 工作，但 AI 執行與治理邏輯在你這邊。

4. 把上游平台分成兩類

System of Record

例如：

Linear for task issue records
GitHub for code and PR records

System of Orchestration

例如：

Bullinv Forge for routing, agent execution, review, audit, skill accumulation

這樣你就不會搞混誰是記錄系統、誰是協調系統。

你最需要避免的事：被平台綁死

這個問題不是「不要用 Linear」，而是：

不要讓你的內部核心語言直接長成 Linear 的樣子。

抗綁定設計原則

1. 內部模型優先

你的核心實體應該是：

Task
Run
Agent
Workspace
Review

不是：

LinearIssue
LinearWorkflowState
LinearComment

2. 每個外部平台都走 Adapter

不要讓上層 service 直接呼叫上游 SDK。

應該是：

TaskRouter
  -> TaskService
     -> ExternalTaskAdapter
         -> LinearAdapter

3. 保留 External Reference Mapping

你應該明確存：

source_system = linear
source_ref_id = <linear_issue_id>
source_url
last_synced_at

這樣你才能未來：

切換到別的平台
同時支援多平台
重建同步狀態

4. 不把 workflow 綁在單一平台狀態機

例如 Linear 有它自己的 workflow states，但你應該有自己的：

queued
claimed
running
blocked
in_review
completed

再由 adapter 去映射到外部平台狀態。

5. 不把 comment / review / blocker 的語意交給上游定義

你應該定義內部語意：

progress_update
blocker_notice
review_request
review_result
handoff_note

然後再決定要怎麼同步到 Linear comment 或 Slack message。

建議的第一版整合組合

如果你要快速起步，我最推薦的組合是：

Linear: 任務與 issue 主入口
Slack: 通知與人機互動入口
GitHub: code / PR / review
Bullinv Forge: orchestration、agent runtime、run log、review、skill

各工具適合扮演的角色

`Linear`

適合：

task creation
project / issue management
status board
team visibility

`Slack`

適合：

通知
人工接手
blocker 提醒
approval request

`GitHub`

適合：

code source of truth
PR review
issue linkage
CI / checks

`Notion` 或文件系統

適合：

長文文件
playbook
skill documentation
project notes

第一版產品策略

第一版不該是「完全取代 Linear」。

而應該是：

Bullinv Forge 疊加在 Linear 之上
讓 Linear 繼續做它最強的 task management
你專注在 AI-native orchestration

之後的演進方式

Phase 1

先做 LinearAdapter
同步 tasks
agent 可接單
回寫 comment / status / blocker

Phase 2

加 SlackAdapter
加 GitHubAdapter
加 richer review / handoff

Phase 3

支援多 task source
支援不只 Linear
形成真正可替換的 integration layer

一句話總結

你不應該重做 Linear；你應該把 Linear、Slack、GitHub 這些成熟工具當成上游能力，然後在上面建立 Bullinv Forge 的 AI-native orchestration layer。

真正要避免的不是「用別人的平台」，而是「讓自己的核心模型直接變成別人的平台模型」。