CLOVE 后台与官方系统，怎样连起来？完整证据链、九个追问与原始档查证
一个管理网址，可以被说成仿站。一张截图，可以被质疑剪裁。但当公司公告、官方程式、Google 专案设定与较早的网页封存，逐段接上同一条线，问题就不能只靠一句「与我们无关」带过。
这篇把来源摊开。你可以不接受本鹦鹉的判断，但应该有机会亲手核对：我们读到甚么、哪些资料互相吻合，以及哪一段仍需要平台拿出纪录。
查证基准：2026 年 9 月 5 日。本文所列的九种说法是预先分析的可能解释，并非 CLOVE 已经作出的回应。
不相信？打开原始码，自己看：三步图解
不用先相信本鹦鹉。把网址打开，把名字贴进搜寻框，原始码就在眼前。 以下四张都是实际 Chrome 画面；点图可放大。
第一步：认清管理登入入口，再对 Google 的清单
先开启这个管理登入入口。它会带到登入页。这张图让你认清入口；要确认它与 CLOVE 官方系统的关联，再看下一张清单。
官方网站与管理登入页的程式使用同一组专案设定。Google 回传的同一专案清单，更同时列出 clove.jp、oripa.clove.jp、clv-admn-next.vercel.app。打开 Google 回应的保存原件，就能自己对照。这支持两边在专案设定上的关联；清单不是公司所有权证书。
第二步：直接开两份公开前端程式
不用帐号，也不用按登入。直接点开：
- 操作定义：2902-1b4cb7dff6c6ef54.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 证据加分；同一把尺，也用来检视我推荐的平台。