CLOVE 后台与官方系统怎样连起来：完整证据链与查证步骤
一个管理网址，可以被说成仿站。一张截图，可以被质疑剪裁。但当公司公告、官方代码、Google 项目设定与较早的网页封存，逐段接上同一条线，问题就不能只靠一句「与我们无关」带过。
重点
- 查证基准日 2026 年 9 月 5 日，全部来源可自行打开。
- 两份 Google 回应逐字节相同，项目编号 385949280493。
- 保存记录列出 24 个可读 Wayback 副本。
这篇把来源摊开。你可以不接受本鹦鹉的判断，但应该有机会亲手核对：我们读到什么、哪些资料互相吻合，以及哪一段仍需要平台拿出记录。
查证基准：2026 年 9 月 5 日。本文所列的九种说法是预先分析的可能解释，并非 CLOVE 已经作出的回应。
不相信？打开源代码，自己看：三步图解
不用先相信本鹦鹉。把网址打开，把名字贴进搜索框，源代码就在眼前。 以下四张都是实际 Chrome 画面；点图可放大。
第一步：认清管理登录入口，再对 Google 的清单
先开启这个管理登录入口。它会带到登录页。这张图让你认清入口；要确认它与 CLOVE 官方系统的关联，再看下一张清单。
官方网站与管理登录页的代码使用同一组项目设定。Google 返回的同一项目清单，更同时列出 clove.jp、oripa.clove.jp、clv-admn-next.vercel.app。打开 Google 回应的保存原件，就能自己对照。这支持两边在项目设定上的关联；清单不是公司所有权证书。
第二步：直接开两份公开前端代码
不用账号，也不用按登录。直接点开：
- 操作定义：2902-8f2cdd12f9517a68.js——看完整操作名称与传入参数。
- 日本管理页：list-0f33ebdda397cc72.js——看页面怎样提交卡池 ID、读取结果。
密密麻麻很正常：这是网站发给浏览器的代码文字。保持原样，接着搜索。
第三步：按 Ctrl＋F，贴上这个完整名称
Windows／Linux 按 Ctrl＋F；Mac 按 ⌘＋F。贴上下面整段，不要加空格，再按 Enter：
scheduleAssignGuaranteedWinOripaUsers操作定义文件有 2 处命中；日本管理页文件有 3 处。 这是2026年9月5日本次读取的版本；之后若网站换了文件，可对照下方原始包的保存版本。
这个名字确实存在，管理页也确实处理它的返回结果。 画面能直接查证到这一步。后端如何选人、在哪次付费交易执行，仍需平台的执行与交易记录。
图解与代码读回日期：2026-09-05。图片、来源及文件指纹。本图解为新增补充；既有 ZIP 保留各自的封存版本与签名。
先用一间店，把整条线讲明白
想象一间店有个你未见过的后房。我们要做五件事：
- 看店主介绍。 公司自己有没有说，这个品牌是自己的服务？
- 对表格编号。 店面与后房的资料，有没有写同一个部门号码？
- 查登记地址簿。 提供系统的 Google，是否也把两个地址列在一起？
- 翻旧副本。 较早由别人保存的资料，是否与今天看到的一样？
- 问工作做过没有。 手册写有一项工作，还要拿值班记录，才能知道何时做过。
前四步已有可以逐份打开的材料。第五步，要靠实际执行与交易记录。同一间店的关系接上了，不等于已经看见谁把哪份奖品交给谁。
「店、后房、地址簿」是帮助理解的比喻。下面保留真实来源：地址簿对应系统的授权跳转清单，不能当成店契或员工名册。
打开原始资料与详细对照
第一条线：公司自己把产品连了起来
TrustHub 官网把「クローブオリパ」列为旗下服务，连到 oripa.clove.jp。Apple 的 Clove 页面列出供应商 TRUST HUB, K.K.；公司原发公告及 SMBC 2024 年 10 月 15 日公告，也支持 TrustHub 与 Clove 产品的关系。
这一步回答的是「公司与产品有没有关系」。接着，才轮到管理网站。
第二条线：官方前台与管理登录页，指向同一项目
把 clove.jp 官方代码与管理登录页代码放在一起，能找到相同的公开 Firebase 设定：
| 识别项目 | 两份代码的共同值 |
|---|---|
| 项目 ID | clove-v2-prd |
| App ID | 1:385949280493:web:224ed7999dd0740cfdc4e4 |
| 认证域名 | clove-v2-prd.firebaseapp.com |
两份代码的公开设定 key 哈希也相同，完整对照在身份包的 identity-chain-sources.json。这些是公开应用代码的项目识别资料。Firebase 文件说明，这类 key 用来识别项目；本身不能当作后台登录权限。
有人可以复制一段公开代码。所以，调查不能停在「设定一样」。下一步才是这次补件的关键。
第三条线：Google 返回的清单，也列了管理域名
2026 年 9 月 5 日 03:56 UTC，分别使用上述两份代码的公开设定识别资料，从 Google 的公开项目设定端点取得 HTTP 200 回应。两份回应逐字节相同，项目编号都是 385949280493。
其中的 authorizedDomains 同时包括：
clove.jporipa.clove.jpclv-admn-next.vercel.app
关联已经延伸到 Google 返回的项目设定。 要把这个管理域名解释为与官方系统毫无关系，就必须同时交代：它为何出现在这个项目的授权域名清单。
这个字段的用途也要说准：Google 定义是登录组件可跳转的授权域名。它支持项目设定层面的技术关联，并不列出公司法律持有人、Vercel 账户持有人或当日操作员。要查到谁加入域名、何时加入、谁控制部署，就要接上 IAM、设定变更与部署历史。
两份 Google 原始 JSON 都在身份包的 public-captures/，共用 SHA-256：
7a574650bdfa74f1460bb31500d691ff8d6a386660b56cfe21239675e936228b第四条线：较早的第三方封存，让版本有迹可循
Wayback 在 2026 年 8 月 23 日 02:14:55 UTC 保存的官方 JS，与 9 月 5 日保存的官方 JS 逐字节相同。这表示这份官方代码并非只在本次整理时才出现。
它的 SHA-256 是：
df59333f5c2ff7ff223e7b321575fd86c6d6aaaa86622f84fa9946ecf70204fa管理登录 JS 的 9 月 5 日封存也与保存原件相同。SMBC 与公司公告另有可读副本；Apple 副本可读，但与本次下载的内容哈希不同，不能把它写成完全相同的原件。
较早的官方 JS，不能替今天的 Google 设定补上整段历史。每份材料的时间，必须各自保留。
目前可以连起来的是：公司 → Clove 产品 → 官方代码与管理代码的共同项目 → Google 清单中的管理域名。 对这条链提出异议，需要指出哪一份来源有错、哪一段推导不成立。
身份接上了，再看后台到底做什么
日本、v2、香港及两个美国库存管理版本，都有用户分配调度的界面实现。日本管理代码包含选取商品、输入检查、提交调度及读取结果；共用操作定义列出 scheduleAssignGuaranteedWinOripaUsers。跨版本原始链接见主文。
这次完整上下文也保留了「アド确定オリパ」提示。该段调用提交 oripaIds，即卡池／商品 ID；没有在这段操作中输入任意中奖者的用户 ID。资格分配是需要查清的具体解释，不能被函数英文名称盖过。
身份关联，回答「这套代码与谁的系统相连」。执行记录，才回答「它做过什么」。 这是同一条调查的下一段，不能用前一段冒充后一段。
九种可能说法，逐项对照
以下每一项都列出现有材料能追问的地方，以及能把争议真正说清楚的记录。平台日后若回应，应另附原文、日期及出处，不把下列假设改写成它说过的话。
1.「这是仿站，与我们无关」
像说「后房不是我的」。那就请把相同编号和地址簿上的连接一起解释。
打开原始资料与详细对照
复制品牌外观，解释不了整条关联。官方 JS、管理 JS 的共同项目，加上 Google 回应中的管理域名，使「完全无关」需要具体说明。可核对的答案是 Vercel 项目及团队控制记录、Google 授权域名变更历史，以及公司与开发商的部署关系。单说「不是我们的」，没有回答这些资料。
2.「那只是外包、旧版或测试环境」
像说「这是外包的旧工作室」。可以，请拿出它何时使用、替谁工作的记录。
打开原始资料与详细对照
管理共用代码指向多个 api.prd.*.clove.jp 主机，并与官方页面共用项目设定。这让环境用途成为可查的问题。prd 命名本身仍不能证明正式执行；版本对应、部署日期、路由配置及流量记录，才可以判定哪段时间服务什么用途。
3.「截图或代码被你改过」
像说「你换了那张纸」。那就把纸的原件与别人保存的副本，一张张对。
打开原始资料与详细对照
请指出文件、位置及差异。读者可以把公开包内的原始字节、SHA-256、当时来源及第三方封存互相比对。相符的 Wayback 副本增加了独立比对点；时间戳则固定所签哈希。哈希只证明文件是否一致，时间戳不会替文章的推论背书。
4.「只是没用到的代码」
像说「手册有写，但从未做过」。查值班簿与工作记录，才知道。
打开原始资料与详细对照
目前展示的是候选商品查询、界面检查、操作调用及回应处理连成的流程，足以追问用途。要查是否执行过，仍要看后端 resolver 版本、工作建立与完成记录，以及相应资料表。界面已整合与曾经执行，应各用对应资料回答。
5.「只是正常的アド确商品资格分配」
像说「我只是派优惠场的入场券」。那就看当时公开的入场规则，与实际派给谁是否一致。
打开原始资料与详细对照
这个解释有上下文支持，必须正面核对。请列出选人规则、资格条件、适用商品 ID、购买限制、付款前的公开说明，以及分配结果；再说清楚它与普通奖池的边界。若记录显示它只分配已披露的优惠资格，判断就应跟着记录走。若用途超出披露范围，争点也会变得明确。
6.「没有指定得奖者，也没有付费玩家受影响」
要证明某个客人受影响，得拿那个人的收据与结果来对。现在还没有这条完整对照。
打开原始资料与详细对照
目前公开材料没有一条完整的交易对照，足以直接驳倒这句话。需要把商品 ID、执行时间、工作 ID、分配结果、付款及得奖记录连起来，并与玩家付款时看到的条件比较。公开版本应匿名化；完整资料可交由获授权的独立审查者核对。不能把一个函数名，写成每个玩家必输的证明。
7.「封号只是处理多账户，没有灭证」
请人离店，与烧掉他的收据，不是同一件事。要查的是原因与记录还在不在。
打开原始资料与详细对照
官方条款确有针对多账户等情况的账户措施。因此，封号本身不能证明报复或灭证。争议个案需要措施时间、具体理由、申诉处理，以及交易资料的保存、备份与导出安排。失去登录入口，与平台删掉所有记录，是两件需要分别查证的事。
8.「只是 AI 分析错误」
不用相信分析者的名字。打开原件；看错了就改，也让其他人接着查。
打开原始资料与详细对照
AI 报告不能替代来源。这篇提供的是可下载的公开代码、设定回应及封存副本；任何人都可以指出误读。此前把 adminSoftDelete 归到指定日本 list 文件的引证，已撤下：在该文件及已解码历史副本中未找到此字符串。更正一个错误，同时也要求其余证据逐项受检验。
9.「系统已经改了」
今天换了新手册，旧手册还是旧手册。新旧各写什么，要按日期对。
打开原始资料与详细对照
新版本可以改变今天的功能，不能改写旧版本曾公开提供的内容。比对时请附更新日期、版本、修改范围及部署记录。删除或修改本身，也不能自动当作认错、报复或曾经操控抽奖的证据。
原始资料、公开分析与封存证明
资料直接放在本站。两个 ZIP 是供读者查证的公开重整版：原始回应与代码保留原字节，说明文字重新编写；内部编辑笔记不混入公开稿。包内 DISTRIBUTION.json 逐个文件列出保留、重整及省略的项目，SHA256SUMS.txt 用来核对这一版内容。
这些新 ZIP 有各自的 RFC 3161 时间戳；文件名加上 .tsr 即是对应签名，.tsq 是请求。原封存包的旧哈希与旧签名另存于 prior-seals/，只对应原包，不能拿来验证重整后的新 ZIP。最早的来源包另保留来源清单的签名，签的是该清单。
截至本次整理，保存记录列出 24 个可读 Wayback 来源副本，以及一份 Archive.today 历史文章。历史文章保留当时文字，更正以现版主文为准。Arquivo.pt 的 20 个记录仍待公开整合确认，Google 设定的 Wayback 工作未完成，Perma.cc 没有完成回执；这些不计入保存成功。
不靠本鹦鹉，自己动手查
第一步：核对你下载的是哪一份
下载 ZIP 与 release.json，比较文件大小和 SHA-256。Windows PowerShell 可执行：
Get-FileHash -Algorithm SHA256 -LiteralPath .\clove-identity-public-20260905.zip解压后，在包的根目录执行随附的 python verify_files.py，逐一核对 SHA256SUMS.txt。它只读本机文件，不连线，也不执行证据包内的 JS。
第二步：沿着来源找到原文
公开来源包从 capture-manifest.json 查网址、保存时间、HTTP 状态及文件；身份包从 additional-public-manifest.json 与 identity-chain-sources.json 查起。Apple、公司公告及 SMBC 的部分补件没有保留下来完整 HTTP 标头，清单有明写，不把缺失补成 HTTP 200。
用文字编辑器开启两份 JS，搜索 clove-v2-prd、App ID 及认证域名；再开 public-captures/admin-firebase-public-config.json，核对 projectId 与 authorizedDomains。对照 Google 字段定义，便能自己判断这条连接能支持什么。
第三步：读操作的前后文
在日本 list 文件搜索 scheduleAssignGuaranteedWinOripaUsers、oripaIds、「アド确定オリパ」及「ユーザーの自动割り当て予约」。看提交参数、候选商品及回应处理，再到共用 chunk 核对操作定义。只截取英文函数名，会漏掉决定用途的上下文。
四份较晚找回的 JS 在 recovered-missing-entries/，哈希与旧清单一致，但取得时间是 9 月 5 日；它们不会被改写成原包当时已收录。
第四步：核对第三方时间与签名
Wayback 网址内的 14 位数字是该副本的 UTC 时间。打开实际 replay，核对最后落到的网址与文件哈希；提交工作成功不等于已经有可读副本。动态页面的 HTML 不同，也不应直接判定造假。
要核对新 ZIP 的时间戳，下载同名 .tsr，以及本站提供的 FreeTSA CA 证书和签署证书，在同一文件夹执行：
openssl ts -verify -data clove-identity-public-20260905.zip -in clove-identity-public-20260905.zip.tsr -CAfile cacert.pem -untrusted tsa.crt成功结果为 Verification: OK。也可以依 FreeTSA 官方方法独立取得证书。信任基础是该时间戳机构与其证书链；这里没有宣称 Bitcoin 锚定。时间戳证明对应哈希在签发时已存在，并不证明网站作者身分、实际抽选结果或指控成立。
最后要接上的，是玩家的交易
现在，身份关联已有可以逐段重查的材料。真正能厘清玩家是否受损的，是同一批商品的规则、分配、付款、结果与账户措施记录。
如果平台能交代，就把记录放到桌面上。如果资料互相矛盾，就指出矛盾在哪里。 这是本鹦鹉要求的答案，也是一篇公开调查应接受的检验。
本鹦鹉对 CARDZ.GAME 的推荐立场与邀请码披露，放在主文末段。推荐不能替 CLOVE 证据加分；同一把尺，也用来检视我推荐的平台。
常见问题
这条证据链证明了什么？
它证明的是身份关联：公司与 Clove 产品、官方代码与管理代码的共同项目，以及 Google 返回清单里同时出现的管理域名。它不证明任何一次抽选结果被改变过。
Firebase 的公开配置可以当成后台权限吗？
不可以。Firebase 文件说明，这类 key 用来识别项目，本身不能当作后台登录权限。所以看到配置相同，还要再看域名清单与部署记录。
我要怎样自己核对下载到的资料包？
先比较文件大小与 SHA-256，Windows 可用 Get-FileHash。解压之后在包的根目录运行随附的 python verify_files.py，逐一核对 SHA256SUMS.txt。它只读本机文件，不联网。
时间戳能证明指控成立吗？
不能。时间戳只证明对应哈希在签发时已经存在，不证明网站作者身份、实际抽选结果或指控成立。信任基础是该时间戳机构与其证书链。
下一步
想先看整篇调查怎么展开，读调查主文。想看网红加成那一段，读神抽背后的秘密。
资料来源
- TrustHub 官网，核实 2026-09-05
- clove.jp 官方代码，核实 2026-09-05
- 管理登录页代码，核实 2026-09-05
- Google Identity Platform 字段定义，核实 2026-09-05
- Firebase API key 说明文件，核实 2026-09-05
- Wayback 2026-08-23 保存的官方 JS，核实 2026-09-05
- 下载清单、SHA-256 与签名资料，核实 2026-09-05