🔀 HOOP → LOOP 分代码方案(2026-09-26,Sora Master)

这份回答一个问题:HOOP 的核心(聊天、通话、工作房、AI)怎么一块块给 LOOP 商业版用,而且以后两边都改、不会分成两套对不上的代码。

起因:Jeff 2026-09-26 15:49 在 Source Code 房的语音:「我们这个代码,我想从 HOOP 搬到 LOOP,就是我们的商业版……他不需要我们的游戏,但是聊天、工作房、AI、哨兵,我要一块一块搬过去……他改的东西我也改,但是在 LOOP 软件层面我不管,核心的核心……你跟我设计一下。」

读取时刻与基线:origin/master eeb3234c1(2026-09-26)。§3 的依赖表是 git grep 每个包的 import 数出来的,行数是 wc -l,不是估的。

状态:方案,还没动一行代码。 动手前要 Jeff 定的三件事在 §7。

0. 一句话

不复制,拆核心。 把两边都要的那一块抽成独立仓库 hoop-core,HOOP 和 LOOP 都依赖它;各自的产品层随便改,核心只在一个地方改。

1. 为什么不直接复制一份

复制那天两边一模一样,一个月后就是两套代码:

LOOP 修了一个聊天的 bug,HOOP 里还在;HOOP 修的,LOOP 也没有。
每修一次都要手抄两遍,漏抄一次两边就开始对不上,而屏幕上看不出谁是新的。

这正是铁律 23 说的「同一件事只能有一个出处」。复制 = 两个出处。

2. 推荐的结构:三个仓库

仓库	里面是什么	谁能看	谁能改
`hoop-core`	登录、用户、好友、会话、消息、通话、在线状态、通知、工作房、AI —— 两边共用的那一块	HOOP + LOOP	两边都能提合并请求,HOOP 这边审过才合
`hoop`(现在这个)	依赖 core + 游戏、城堡、音乐、钱包、羁绊、温度…… 只有 HOOP 有的	只有 HOOP	HOOP
`loop`(新的)	依赖 core + LOOP 自己的界面和功能	LOOP(+ HOOP)	LOOP 随便改

核心改动只能在 hoop-core 里改。 两边各自升级 core 的版本号拿到新核心 —— 谁什么时候升,自己定,不会被对方突然改坏。
后端 core 是一个独立的 Go 模块(现在的模块名是 github.com/jeffchoong/hoop/backend,core 要有自己的模块名);App core 是一个 Dart 包。
LOOP 那边永远只拿得到 hoop-core 和 loop,拿不到 HOOP 主仓。 游戏、经济、城堡这些不出门。

3. 难点:核心现在不是干净独立的(实查)

后端每个候选核心包 import 了哪些别的包:

核心包	行数	它牵着的(非核心的加粗)
auth	6057	—(干净)
user	1764	auth · bond(羁绊)
friend	2160	auth · block · notification · bond · warmth(温度)
conversation	6218	auth · notification
message	14851	auth · block · callkeys · calls · conversation · presence · post(帖子)· room(房间)· risk(风控)
calls	10735	auth · callkeys · notification
presence	474	auth · friend
notification	742	auth
workroom	9413	ai · assistant · auth · contrib · developer(开发者平台)
assistant	4291	ai · auth · block · conversation · message · wallet(钱包,扣 Sparks)
ai	1875	auth

另外 auth / conversation / message 还 import 了 internal/ops(管理后台那一层),搬之前也要看清是拿它做什么。

所以搬之前要先「剪线」:核心里只留一个接口(比如「给这句话算温度」「扣这个人的额度」),HOOP 把温度、钱包接上去,LOOP 接自己的,或者不接(空实现)。

App 这边更缠:聊天页 app/lib/screens/chat_screen.dart 一个文件 13906 行,里面混着 HOOP 独有的东西(grep 数的:提到 game 27 处、warmth 38 处、sticker 205 处)。这块要最后、最小心地切。

这是真工作量,不是复制粘贴。 所以要一块一块来,每一块都能单独验。

4. 顺序

块	搬什么	为什么排这里
第 1 块	登录 + 用户 + 好友 + 文字聊天(会话、消息、通知、在线状态)	最小能跑的一版,先让 LOOP 部署起来、有人能登录、能聊
第 2 块	通话	本身比较独立(只牵 auth / callkeys / notification)
第 3 块	工作房	要先把「开发者平台」那根线剪开
第 4 块	AI 助手	要先把「钱包扣额度」那根线剪开;LOOP 用不用 Sparks 由 LOOP 定
以后	哨兵	Jeff 说新做,不从 HOOP 搬

每一块都走同样四步:

在 HOOP 里把这块的线剪开(换成接口),不改任何行为
HOOP 自己跑一遍:编译、全部测试、真机看过 —— 确认 HOOP 没被剪坏
把这块搬进 hoop-core,HOOP 改成从 core 拿
LOOP 接上这一块,在 LOOP 自己的服务器上跑起来

第 1、2 步只动 HOOP,随时可以停;到第 3 步才出现新仓库。

5. 数据库

HOOP 现在有 398 个迁移,大半是游戏、经济、城堡的表。LOOP 不继承这一串。
core 带自己的一套迁移,只建核心那几张表;LOOP 从零建库,只跑 core 的迁移 + LOOP 自己的。
HOOP 这边已经有的核心表,表名和字段不改(改了要迁移,还会让装在用户手机上的旧包炸)。core 的迁移要写成「表已存在就跳过」,这样同一套迁移在 HOOP 的老库和 LOOP 的新库上都能跑。

6. 必须守住的几条

LOOP 永远看不到 HOOP 主仓。 只给 hoop-core 和 loop 的权限。
密钥一个都不带过去。 每一块搬之前扫一遍:钥匙、证书、服务器地址、api.hoopcomm.com 这类写死的域名,全部换成配置。扫的命令和结果写进那一块的提交说明。
LOOP 用自己的服务器、自己的数据库、自己的推送证书、自己的 App ID。 不和 HOOP 生产共用任何一样 —— 共用的话,LOOP 一次误操作会动到 HOOP 的真用户。
核心归谁、改了算谁的,写一张简单的约定。 就算是自己人,以后团队会换人;没写下来的东西,换一个人就没人记得。
往外部仓库推代码,每一次都要 Jeff 给的仓库地址。 不自己建外部仓库、不往没确认过的地址推(铁律 30)。
历史记录也算「带出去」。 如果搬的时候连 git 历史一起带(方便追「这行谁改的」),历史里曾经提交过又删掉的钥匙也会跟着出门。所以:要么不带历史、从干净的一版开始;要么带之前把历史整段扫一遍。第 1 块默认不带历史。(Cora Master 09-26 提的)
第三方依赖的许可证要核一遍:给另一家公司用,和自己用不是一回事。

6½. 核心怎么管(Cora Master 09-26 补的,我同意)

核心边界清单跟核心代码放在同一个仓库。 每块写清:包含什么、对外接口、两边负责人、测试要求。按目录划,不逐个文件登记(逐个登记 = 一改就漏)。
谁同意才能改: · 核心的接口、数据结构、行为变了 → 两边各一名负责人同意才合 · 核心内部修 bug、不改接口 → 按约定的维护权限处理,不用两家全员点头 · LOOP 自己的界面和业务规则 → LOOP 自己定
两边各自钉版本。 比如 HOOP 用 core 1.2、LOOP 用 1.1;core 发 1.3 后,两边分别测、分别升。不会一合代码就同时改动两个线上产品。
合进核心之前,两边的兼容测试都要过。 数据库升级也各自在自己的环境跑,一边先升不能逼另一边当天跟。
抽哪块,那块就要两边真的引用同一份代码。 只给 LOOP 拷一份、HOOP 还留着旧实现 = 还是两套。第 1 块(登录 + 聊天)就是用来验证这条路走得通的。

7. 动手前要 Jeff 定的三件事

新的 GitHub 仓库:建好了吗?地址是什么?(hoop-core 和 loop 两个,还是 LOOP 那边已经有一个?)
LOOP 的后端:是自己一台服务器吧?谁管?
第一块先搬「登录 + 聊天」,同意吗?

8. 我没做的 / 不确定的

App 端的依赖我还没逐文件数,只量了聊天页的大小。App 第 1 块真动手前要先出一张和 §3 一样的表。
工作量没估天数。 第 1 块剪完线、HOOP 跑通之前,估出来的天数都是猜的。
internal/ops 被核心 import 的那几处具体用途还没看。
这份方案还没给 LOOP 那边的人看过。他们的技术栈、要不要用我们的 App 壳、界面要改多少,都会影响 §4 的顺序。