一間場館從「地圖上還不存在」到「館主確立、平台代收的錢撥得出去」，
中間有哪些身分、哪些審核、每個時期各自握有什麼權限。
這頁是行為規格的圖解版；文字正本在
docs/ArenaMate_場館上架與所有權_交接.md。
所有權限分界都從這一句推出來。記住這句，其餘的規則都不用背。
平台不經手這筆錢。場館資料審過就能做：開場次、排時段、收現金入場費。
⚠️ 不讓管理員收現金，場次根本開不成 —— 館主常常懶得聲明所有權，冷啟動就死在這裡。
教練開課、聯誼賽報名費、區域聯賽。平台收了錢之後要撥給場館，必須先知道撥給誰。
⚠️ 人工核可 且 館主確立 —— 是 AND 不是 OR。
verify_tier — 這個館的資料被驗到什麼程度ownership_status — 所有權在誰手上⚠️ 兩條軸是獨立的，不要混在一起。 「審過了」不等於「知道館主是誰」；「館主是誰」也不等於「資料驗過了」。 平台代收要兩條軸同時到位。
每一格都標了當下的資料庫狀態、誰是誰、以及那個時期實際能做什麼。
球員搜尋不到、約不了球。這是我們要解決的起點。
流程：先問一個是非題「你是這間場館的老闆嗎？」→ 填座標時自動偵測附近 500 公尺內已有的場館，列出來問「是不是這一間」→ 填樓層、正面照、球場照、身分證。
⭐ 建館的人一律先是 admin，不再直接是 owner。 舊行為「誰建誰就是 owner」等於開了一條自助升級成金流控制者的路 —— owner 就是收款帳戶控制權。
核准＝「這個館的資料驗過了」。場館出現在地圖上，館主就算從缺，照樣可以營運。
⚠️ 核准與 verify_tier 必須綁在同一個交易。
2026-07-27 抓到過一次：核准只改 status、沒動 verify_tier
→ 新館核准後管理員照樣開不了場次。已修（arena_operator_set_gym_status）。
兩個入口：App 進館頁大廳的「館主登記」橫幅，或純網頁
chefsmate.app/gym/<代號>/claim。
⚠️ 網頁版不可以綁 App —— 五十幾歲的館主不會為了登記去下載 App， 會卡死在第一步，而公立場館的窗口正好是這個年齡層。
兩條軸同時到位，平台代收解鎖。
⚠️ 核可＝把這個場館的收款控制權交給這個人。審核台的二次確認要把後果講出來， 不是只問「確定嗎」。同一間館其他還在排隊的登記件會一併結掉。
要更多資料：件留著、場館維持 claiming，可以補件再送。
退回：沒有其他排隊件時，場館退回 unclaimed。
⚠️ 退回後不可以留在 claiming —— 大廳會永遠顯示「審核中」，
真正的館主看到就不會來登記了。
營運照常、金流凍結。
⚠️ 不可以停掉整個館 —— 已經報名的球員沒做錯事。 裁決給另一方時，舊 owner 降成 admin 但不踢出場館（他可能是館方真的員工）， 錢跟著換人。
場地、成員、教練、時段搬到留下來那間；已經發生的事實留在原地
（那場比賽確實是在原本那間館打的）。舊館標 merged_into + 下架，不刪。
⚠️ 不同址一律擋。最嚴重的後果是打卡圍欄只剩一組 → 另一個地點的人永遠打不了卡，而且不會報錯。
這張表就是 GymOwnershipGates.can() 的全部內容，SQL 端 arena_gym_can() 是它的鏡像。
兩邊不一致＝App 顯示可以按、server 拒絕（或更糟：App 擋了但 server 放行）。
| 驗證程度 ＼ 所有權 | unclaimed 館主從缺 |
claiming 登記審核中 |
owned 館主已確立 |
disputed 爭議中 |
|---|---|---|---|---|
| none 剛送件 |
只能看資料 場次、時段、收費全鎖 |
只能看資料 | 只能看資料 | 只能看資料 |
| ai 場館審過 |
營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✗ |
營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✗ |
營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✗（還缺人工核可） |
營運 ✓ 分帳明細 ✓ 現金與代收全凍結 |
| human 人工核可 |
營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✗（還缺館主） |
營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✗（還缺館主） |
全開 營運 ✓ 現金 ✓ 分帳明細 ✓ 平台代收 ✓ |
營運 ✓ 分帳明細 ✓ 現金與代收全凍結 |
⭐ 注意整個 ai 那一列：館主從缺照樣可以開場次、收現金。 這一格就是冷啟動能不能活的關鍵 —— 台灣多數公立場館的常態就是館主從缺。
最常被問的一句。六根骨頭把所有可能的原因一次攤開；由左往右愈接近使用者實際會遇到的那一步。
⭐ 下面兩根（館型走錯路、平台自己沒設好）最容易被忽略， 因為它們看起來都像「館主不配合」，實際上是我們這邊的問題。 公立場館拿不到電費單，用同一套文件標準會把全台最大一批場館永遠鎖在館主從缺。
建館第一步的是非題「你是這間場館的老闆嗎？」就是在分這三條路。
proxy · 回答「不是老闆」
private · 回答「是老闆」→ 私營
public · 回答「是老闆」→ 公立
someone@gov.tw.attacker.com 裡面也有 gov.tw。
「人」永遠是 user_profiles.id（身分大一統）；per-gym 的角色記在 gym_members。
看場館、報名場次、打卡入場。看不到任何審核文件。
開場次、排時段、管成員、改場館資料、收現金入場費。 建館的人一律先是這個身分 —— 未經審核的所有權主張不可以直接拿到 owner。
admin 的全部，再加上平台代收：教練開課、聯誼賽報名費會撥到他設定的帳戶。 只有 operator 人工核可才拿得到。
拿不到電費單（電費掛在市政府或教育局名下）。改用 @*.gov.tw / @*.edu.tw 收一次性驗證碼，全自動，不用人看文件。
文件常在公司／房東／前手名下。名字對不上走人工判斷，不自動退件。
核准場館上線、裁決館主登記、處理爭議、合併場館。 唯一能改所有權欄位的身分 —— 其他人寫進去會被 server 直接還原。
三條泳道：申請人做什麼、系統自動做什麼、operator 做什麼。
它只查得到機械性的關聯，沒有看過文件內容：
寫成「AI 審過了」會讓審件的人少看兩眼，而這正是最不能出錯的地方。 而且「沒查到疑點」也只代表機器沒看到問題，不代表可以自動核可 —— owner 就是收款帳戶控制權。
這些不在主流程上，但少了任何一個，主流程都會在真實世界裡壞掉。
填座標時自動列出附近已建好的場館，問「是不是這一間」。不硬擋，但這題一定要答。
⚠️ 重複建館的後果不是資料難看，是球員進錯館、打卡打到隔壁那間——而且不會報錯。
同一棟樓的好幾間館收成一個圖釘，點開靠樓層徽章 + 正面照挑。門牌優先、座標備援。
⚠️ 同一棟樓的 GPS 誤差常比 50 公尺大 → 純靠螢幕距離群集，放大就會拆成好幾個疊在一起的點。
同址多館時，列表上就只有這兩樣分得出來。正面照走公開 bucket（給球員認路）。
⚠️ 審核文件走私有 bucket，用途不同不可混放。
一般使用者改不動 verify_tier / ownership_status / status —— 寫進去會被還原成舊值。
⚠️ 補洞前 gyms 的 UPDATE policy 是 using(true)：任何登入者都能把自己相中的館寫成 owned+human。
6 碼、15 分鐘、最多試 5 次、24 小時最多寄 5 封、兩封間隔 60 秒。只存 SHA-256，不存明碼。
⚠️ 沒有頻率限制的話，任何人都可以拿我們的寄信管道去騷擾公務信箱。
身分證這類文件在裁決後 30 天清除（doc_purge_at / id_doc_purge_at）。
⚠️ 讀取只給 operator 與上傳者本人。
chefsmate.app/gym/<代號>/claim。Email 收一封信就登入，不設密碼、不下載任何東西。
⚠️ 代號吃 slug 或 uuid —— 只認 slug 的話，還沒有 slug 的館這頁是死的。
搬：往後還會用到的（場地、成員、教練、時段）。留：已發生的事實（比賽、分錄、評價）。重算：統計值。
⚠️ 統計值重算不是相加 —— 兩個半滿的館加起來不等於一個滿的館。
程式全部在 main 上、DB 全部 apply 過、寄信設定也到位了，但兩封真的信（網頁登入 magic link、公務信箱 6 碼）都還沒有人實際收過。
verify_tier 狀態機（建館 none → 核准 ai → 核可 human）目前只有線上手動實測，欠 CI 自動劇本。
文字正本：docs/ArenaMate_場館上架與所有權_交接.md ·
規則層：Apps/arena_mate/lib/data/gym_ownership.dart ·
測試地圖劇本 S75–S80：arena-testing.html
← 回 ChefsMate 主控台