main 由来の prices/products/invoices/checkout と auth 由来の payments/membership の機能重複を整理する

現状

packages/api/src/router.ts が束ねる 8 つのルーターのうち、次の 3 組が同じ対象を扱っている。

• Invoice の一覧: invoices.list と payments.listInvoices
• Checkout Session の一覧: checkout.sessions.list と payments.listCheckoutSessions
• Invoice の発行: invoices.issue と membership.issueInvoice / membership.issueSpecialInvoice / membership.issueSpecialInvoiceByEmail

認可の付き方が組ごとに違う。prices・products・invoices・checkout の 4 つのルーターは packages/api/src/orpc.ts の pub で実装されていて認可ミドルウェアを持たず、変更系だけが同じファイルの assertMutationsEnabled で塞がれている。payments は adminProc、membership は userProc と adminProc で実装されている。

画面から呼ばれているのは後者だけである。2026-09-18 に git grep -ohE '\$orpc\.[a-zA-Z.]+' -- 'apps/web/app' | sort -u で数えたところ、apps/web/app が呼ぶプロシージャは auth・membership・payments・payouts の 12 個で、prices・products・invoices・checkout を呼ぶ箇所は 0 だった。

誰が何を誤るか

Invoice の一覧や発行に手を入れる人が、2 つあるルーターのどちらが正しい置き場所かを判断できない。認可の弱い pub の側に足すと、無認証で到達できる経路が増える。また、両者の出力の形が違う（invoices.list は Stripe の語彙をほぼそのまま写し、payments.listInvoices は product と paymentId と dashboardUrl を持つ正規化済みの行）ので、一方だけを直すと画面と管理用の経路で見えるものがずれる。

取りうる手

• 画面から呼ばれていない prices・products・invoices・checkout を契約から外す
• 認可を payments / membership と揃えたうえで、管理用のエンドポイントとして残す
• 出力の形を payments の正規化済みの行に寄せ、invoices.list を内部化する

直さずに残した理由

削除も認可の付与も公開している契約の変更で、#15 が決める認可の形に結論が依存する。認可の形が決まる前に片方を消すと、決まった後で作り直しになる。

Start with packages/api/src/router.ts and packages/api/src/orpc.ts to map the overlapping routers and their authorization middleware. Check the web call sites with the documented git grep command, then read issue #15 before choosing whether to remove, secure, or internalize the unused procedures. Done means the duplicate contract and authorization behavior are resolved consistently.