集酒（shushu）— テスト環境を用意し、図鑑の「収集済み / 未収集」の不具合を直した

• テストアカウント 7 人・投稿 21 件（写真つき 14 件）・フォロー関係 12 件・乾杯 10 件を作る投入スクリプトを用意した。python3 scripts/seed-test-data.py の 1 行で、何度でも同じ状態に戻せる。
• 図鑑の「収集済み / 未収集」は、記録の有無に関係なく必ず失敗していた。 原因は「全銘柄を取ってから、その全 ID を URL に並べて自分の投稿を引く」実装で、マスタ 500 件だとリクエスト URL が約 18KB になり HTTP 414（URI too long） で弾かれていた。銘柄が約 200 件を超えると必ず起きる作りで、本番の 151 銘柄でも危険水域だった。絞り込みを DB 側でやる形に直し、URL は 267〜329 文字になった。
• 直す過程で別の不具合を 2 件見つけて直した。乾杯の件数が他人の投稿では絶対に増えない（RLS がトリガーの UPDATE を弾いていた。乾杯ボタンを付けた瞬間に表に出る）、管理 API / ダッシュボードからユーザーを削除できない（乾杯を 1 件でも持っていると 500 で失敗）。どちらもトリガー関数の設定が原因で、マイグレーション 1 本にまとめた。
• 直していないが決めてほしいことが 1 件（5 章）。非公開アカウントの公開投稿が、フォローしていない人の「新着」に出る。

cd business/shushu/shushu-supabase
npx supabase start                     # 落ちているとき
python3 scripts/seed-test-data.py      # テストデータを作り直す

cd ../shushu-app
npx expo start                         # Metro。シミュレータのアプリは入っている

テスター太郎で

• ホーム「新着」に他人の公開投稿が並ぶ（19 件。写真・★・🍻の数・銘柄名・蔵元）
• ホーム「フォロー中」は 17 件。花子の親しい友達限定の投稿が見えている
• 投稿をタップ → 投稿詳細。自分の投稿なら編集・削除
• 図鑑「すべて」= 500 銘柄。「収集済み」= 6 件・「未収集」= 494 件（今回直したところ）
• 図鑑のフィルター（産地=秋田県 → 収集済み 2・未収集 11／種類=純米大吟醸）
• 図鑑ヘッダーの「＋ 図鑑未登録の記録 1 件」（自由記述で記録した「森のくまさん 純米」）
• 収集済みのセルに「済」バッジ・★・「新政」に ×2
• 銘柄をタップ → 銘柄詳細に自分の投稿履歴
• マイページ: 酒好プロフィールのレーダー・マイランキング Top3・投稿グリッド・フォロー 3 / フォロワー 3
• FAB 長押し → 下書き一覧に 1 件（剣菱 ひやおろし）
• フォロー一覧 → 検索（h で花子が出る）→ 新しくフォロー
• 新規投稿: 写真・銘柄の候補・★・味のスライダー・公開範囲。投稿したら図鑑が 7 / 500 になる
• マスタに無い銘柄名を打って投稿 → 図鑑ヘッダーの「図鑑未登録の記録」が増える

そらで（非公開アカウント）

• フォロー一覧に「リクエスト」タブが出て、3 件が承認待ち
• 承認するとフォロワーに移る／拒否すると消える

はじめで（何も無いアカウント）

• 図鑑「収集済み」が「まだ記録した銘柄がありません」（今回、文言を足した）
• 図鑑「未収集」が 500 件（全部出る）
• フォロー中タイムラインが空・マイページが空

原因: src/services/collection.ts の getCollectionItems が、収集状態で絞り込むときに次の順で動いていた。

1. ページングをやめて全銘柄（500 件）を取る
2. 取れた 500 件の ID を全部 URL に並べて、自分の投稿を引く（.in('sake_product_id', productIds)）
3. 手元で収集済み / 未収集に分けてから、必要な 30 件を切り出す

2 で作られるリクエスト URL が 約 18KB。Supabase の前段（Kong / nginx）はリクエスト行の上限が 8KB なので、必ず HTTP 414 URI too long で弾かれる。

$ curl -G .../rest/v1/sake_products --data-urlencode "id=in.(<500件のUUID>)"
ids length: 18499
URL length: 18562
HTTP 414
URI too long

2026-09-13 にローカルで実測。UUID 1 個で 37 文字なので、銘柄が約 215 件を超えると必ず起きる。「すべて」タブはページング（30 件）が効いているので ID が 30 個で済み、壊れていなかった。ファーストリリースの 151 銘柄なら偶然セーフだが、少し増やした瞬間に壊れる作りだった。

kanpais に行が入ると update_kanpai_count() が UPDATE posts SET kanpai_count = kanpai_count + 1 を走らせる。この UPDATE は乾杯した本人の権限で実行されるが、posts の RLS は posts_update USING (auth.uid() = user_id)。つまり他人の投稿は 1 行も更新されず、件数は 0 のまま黙って据え置かれる。自分の投稿に乾杯したときだけ増える、という一貫性のない状態だった。

【直す前】他人の公開投稿に authenticated で乾杯
  乾杯する前の kanpai_count: 0
  挿入 HTTP 201
  乾杯した後の kanpai_count: 0      ← 増えない
  実際の乾杯行数: 1

【直した後】
  乾杯する前: 0 → 挿入 HTTP 201 → 乾杯した後: 1
  取り消し HTTP 204 → 取り消した後: 0

いま表には出ていない（アプリに乾杯ボタンがまだ無く、数字を表示しているだけ）。ボタンを付けた瞬間に「全員 0 のまま」になるので、先に塞いだ。

乾杯を 1 件でも持つユーザーを消すと 500: Database error deleting user。DB 側の原因は ERROR: relation "posts" does not exist。

auth.users の削除は supabase_auth_admin ロールで走り、このロールの探索経路に public が入っていない。関数側に search_path が設定されていないと実行時のセッションのものが使われるため、CASCADE で kanpais が消えるときに発火する update_kanpai_count() の中の posts が解決できずに落ちていた。

運営がサポート対応や退会代行でユーザーを消せないという形で効く。なおアプリ内の退会（delete_my_account）は影響を受けない — こちらは SECURITY DEFINER 側で search_path = public, auth を設定しているため。乾杯を持つ捨てアカウントで実測して確認した（HTTP 204・ユーザーは消える）。Google Play のアカウント削除要件は満たせている。

非公開アカウントの公開投稿が、フォローしていない人の「新着」に出る。

いまの is_private はフォローに承認が要るかどうかだけを決めていて、投稿の見え方は変えていない。そら（非公開）の visibility = public の投稿は、フォローしていない「はじめ」の新着にも出る（実測）。

Instagram 型の非公開アカウントは「フォロワー以外には投稿を一切見せない」なので、ユーザーの期待とずれる。直すなら posts_select の RLS に「投稿者が非公開なら、フォロワーか本人だけ」を足すことになる（クライアント側では直せない）。

ただし仕様の決めの問題で、「非公開＝勝手にフォローされないだけ。投稿の公開範囲は投稿ごとに選ぶ」という設計も成り立つ。その場合はラベルを変えるのが筋（「非公開アカウント」→「フォローを承認制にする」）。どちらにするか決めてください。