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 證據加分；同一把尺，也用來檢視我推薦的平台。