X投稿権限をstaff roleで分ける――閲覧・下書き・承認・公開

記事や投稿を編集できる利用者と、外部公開できる利用者を同一権限にしない設計になっているか。

コードから観測できること

1. staff route、DB module、staff migrationがあり、認証middlewareとは別に役割を保存する。
2. 投稿・growth article・scheduleという複数公開経路があるため、一つのrouteだけ権限を確認しても公開権限監査は完了しない。
3. viewer、editor、admin、ownerの期待操作を表にし、UI非表示ではなくAPI直接要求で拒否されることを確認する必要がある。

再現・追加測定の手順

1. 4 roleのAPI keyを作る
2. 閲覧・下書き・編集・予約・即時公開を要求する
3. 別account/resource IDも指定する
4. 応答とD1/X側副作用を記録する

この資料だけでは証明できないこと

1. role名から期待権限を推測せず、実装と文書の一致を確認する。
2. 漏洩した高権限keyへの失効・監査手順はrole設計とは別に必要。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。