Twitter クローン（オンボーディング課題）

Next.js App Router の教材をベースにした Twitter（X）風アプリ。要件は docs/functions.md、画面遷移は docs/front_design.md を参照。

構成

層	場所	役割
shared	shared/	UUID正規化など業務知識を含まない処理。他の層をimportしない
domain	domain/	entities/（ユーザーの型）、value_objects/（入力ルール・画像の状態）、repository_ifs/（永続化の契約）、external_service_ifs/（パスワードハッシュ・セッション終了・ストレージ・画像検査の契約）。フレームワークやDB、上位層に依存しない
application	application/	usecases/<機能>/（登録・投稿などの処理）、dtos/<機能>/（一覧型・結果型）、query_service_ifs/<機能>/（タイムライン・プロフィール・お気に入りの読み取り契約）。Next.jsや具体実装に依存しない
infra	infra/	persistence/postgres/（接続・マイグレーション・repositories/・query_services/）と external_services/（scrypt・Vercel Blob・sharp）。domain/applicationの契約を実装する
main	main/container/	具体実装の組み立て（DI）。Web用は機能別ファイルで server-only・遅延初期化、CLI用は cli/ に置き server-only を使わない
app	app/	画面、Server Action、Route Handler、Auth.js の設定。サーバー側の処理は main/container/ の取得関数だけを呼び、クライアントコンポーネントからは import しない

セットアップ（Vercel + Postgres）

DB は Vercel の Storage から作成する Postgres（Neon）を使う。

1. Vercel にプロジェクトを作成（GitHub リポジトリを Import するか、pnpm dlx vercel link）。
2. Vercel ダッシュボードの Storage → Create Database → Neon (Postgres) で DB を作成し、プロジェクトに接続する。POSTGRES_URL などの環境変数が自動で登録される。
3. Settings → Environment Variables に AUTH_SECRET（openssl rand -base64 32 の値）を追加する。AUTH_URL は Vercel 上では設定しない。
4. ローカルに接続情報を取得してマイグレーションを適用する。

pnpm install
pnpm dlx vercel env pull .env.local   # POSTGRES_URL などを .env.local に保存
pnpm db:migrate                       # POSTGRES_URL_NON_POOLING（なければ POSTGRES_URL）に適用
pnpm dev

• .env.local が .env より優先される。ローカル専用の AUTH_URL などは .env に書く（.env.example 参照）。
• vercel env pull で取得するDBは本番と同じ。開発で分けたい場合は Neon で開発用ブランチを作り、その接続URLを .env.development.local の POSTGRES_URL（プール経由）と POSTGRES_URL_NON_POOLING（プールなし）に書く。pnpm dev と pnpm db:migrate はこちらを優先する。
• Twitter 用のテーブルは PostgreSQL schema twitter に作成する。
• マイグレーションはリクエスト処理やビルドからは実行しない。スキーマを変えたらデプロイ前に pnpm db:migrate を実行する。

テスト用DB

結合テストと E2E はデータを書き込むため、本番・開発とは別の DB を TEST_POSTGRES_URL に指定する。Neon コンソールでテスト用のブランチ（または別の database）を作り、その接続URLを .env に書く。Vercel の環境変数には登録しない。

pnpm db:migrate --test で TEST_POSTGRES_URL 側にも適用できる（テストは自動で適用する）。

テスト

コマンド	内容
pnpm test:unit	domain・ユースケース・Server Action・UI の単体テスト（DB不要）
pnpm test:integration	実 PostgreSQL の Repository と実 scrypt のテスト
pnpm test:e2e	Playwright。テストDBに向けた本番ビルドを port 3100 で起動して検証
pnpm typecheck	型チェック

• 結合テストと E2E は TEST_POSTGRES_URL が必須。未設定、またはアプリ用の URL（Neon のプール経由・プールなしを含む）と同じ DB なら実行前に失敗する。
• テストは自分で作成した行だけを削除し、DB全体の drop・truncate は行わない。
• E2E 初回は pnpm exec playwright install chromium でブラウザを取得する。

アカウント作成の仕様メモ

• 登録画面ではユーザーID・名前・パスワードだけを入力する。自己紹介は空で登録し、プロフィール編集から設定できる。
• ユーザーIDは大文字小文字を区別せず一意（表示は登録時の綴りを保持）。文字数は Unicode コードポイント数で数える。
• パスワードは Node.js 標準の scrypt（N=2^17, r=8, p=1）でハッシュ化して保存する。bcrypt の72バイト制限を避けるため。
• 認証は Auth.js の Credentials + JWT セッション（7日）。セッションには内部 UUID だけを入れる。
• 登録直後の自動ログインだけが失敗した場合は、作成済みのアカウントを削除せず、ログイン画面へ案内する。

ログインの仕様メモ

• /login は登録時と同じ形式ルールでID・パスワードを検証してから認証する。形式違反はAuth.jsへの直接リクエストでも認証ユースケースで拒否する。
• 未登録IDと誤パスワードは同じメッセージ、DB障害などは別のメッセージで区別する。失敗時はIDだけを保持する。
• ログイン済みでセッションのUUIDに対応する利用者がDBに存在する場合、/login は / に移動する。Cookieの有無だけでは判断しない。

メイン画面（タイムライン）の仕様メモ

• 投稿（twitter.tweets）・フォロー（twitter.follows）・リツイート（twitter.retweets）は 002-create-timeline.sql で作成する。利用者を削除すると関連行もcascadeで削除される。
• 一覧は投稿とリツイートを1本のSQL（UNION ALL）で取得し、(出来事の日時, 種類, ID) のキーセットで20件ずつページングする。OFFSETは使わない。
• カーソルの日時はDBのマイクロ秒精度を保つ文字列のまま扱う。postgres.js は timestamptz 型のパラメータを Date（ミリ秒）に変換するため、SQLでは ::text::timestamptz で渡している。
• 投稿の作成・編集・削除（画像付き）・お気に入り・いいね・リツイート・フォローは画面から操作できる。テストのデータはSQLで直接入れる（test/support/timeline-fixtures.ts）。

プロフィール画面の仕様メモ

• /profile/{ユーザーID} は未ログインでも閲覧できる。自分かどうかはDBの対象UUIDとセッションのUUIDで判断する。
• フォロー数は follower_id = 本人、フォロワー数は follow_id = 本人 の件数。向きごとの独立したサブクエリで数える。
• 投稿・リツイート・フォロー・フォロワーの一覧は、それぞれ1回のSQLでキーセット方式（20件）で取得する。カーソルには対象者とタブを含め、他の画面・他人のページへ持ち込まれた場合は不正として扱う。
• 新しいテーブル・マイグレーションはない（002 までを使う）。

プロフィール編集の仕様メモ

• /profile/{ユーザーID}/edit は本人だけが使える。画面の表示時に加え、保存のたびにServer Actionでセッションと利用者を確認し、actorId === targetId のときだけ更新する（フォームの値や previousState は権限判断に使わない）。
• 更新は名前・ユーザーID・bioの3列だけを1つのUPDATEで行う。ID重複は一意インデックス users_display_id_ci_unique の違反だけを競合として扱い、部分的な更新は起きない。
• 保存後は revalidatePath でメイン・プロフィール・編集画面の表示を無効化し、表示用Cookie flash_profile で更新通知を出す（登録通知の flash とは別）。
• textarea の改行はブラウザがCRLFで送るため、自己紹介はサーバーでLFに揃えてから検証・保存する。
• 新しいマイグレーションはない。

アカウント削除の仕様メモ

• 削除画面への導線は、ログイン中のサイドバー（左ナビ）の一番下に置く。プロフィール画面には置かない。
• /profile/{ユーザーID}/delete は本人だけが使える。ページ表示（GET）では削除せず、Server Actionで毎回セッションのUUIDを確認し、actorId === targetId かつ現在のパスワードが一致したときだけ削除する。
• 削除は DELETE FROM twitter.users WHERE id = ... の1文だけで行い、投稿・フォロー・リツイートは既存FKのON DELETE CASCADEで消える（論理削除・復元はなし）。
• 削除後は表示を revalidatePath で無効化し、Auth.jsの signOut({ redirect: false }) で認証Cookieを無効化してから /login へ移動する。通知は表示用Cookie flash_account（deleted / signout-failed / account-missing）で出す。
• DB削除とCookieの変更は1つのトランザクションにできないため、signOutに失敗しても削除は戻さず、その旨をログイン画面に固定表示する。他のブラウザに残ったセッションは、利用者の実在確認で未ログインとして扱われる。
• 新しいマイグレーションはない。

ツイート作成ダイアログ・画像の仕様メモ

環境

• 画像は Vercel Blob の非公開ストアに保存する。開発・本番・テストで別のストアを用意し、アプリ用は BLOB_READ_WRITE_TOKEN / BLOB_STORE_ID（開発は .env.development.local）、テスト用は TEST_BLOB_READ_WRITE_TOKEN / TEST_BLOB_STORE_ID（.env）に書く。
• 結合テスト・E2Eは、実体を作る前にテスト用トークンが宣言したテスト用ストアを指し、アプリ用ストアと別であることを確認する。資格情報がなければskipせず失敗する。
• 003-create-tweet-media.sql を pnpm db:migrate（開発）・pnpm db:migrate --test（テスト）で適用する。既存データの移行は不要。
• Vercel には CRON_SECRET を登録する。vercel.json のCronが毎日 18:00 UTC（日本時間3:00）に回収を実行する（Hobbyプランの日次制約に合わせている）。

流れ

1. 「ツイートする」を押すと、サーバーで利用者を確認して下書き（24時間有効）を作り、ダイアログを開く。未ログインならログイン画面へ移動する。
2. 画像を選ぶと、/api/tweet-images/upload で予約し、予約パス（tweet-uploads/{下書きID}/{予約ID}）だけに書き込める15分のトークンを受け取って、ブラウザから Blob へ直接アップロードする。画像の本体はアプリのサーバーを通らない（Vercel Functionsの4.5MB上限を避ける）。
3. /api/tweet-images/verify で、サーバーが実体を読み（5MBで打ち切り）、sharpでJPEG/PNGとしてデコードできること・画素数（4,000万以下）・Content-Typeとの一致を確かめる。完了webhookは使わない。
4. 投稿のServer Actionには本文と、準備済みの予約IDの並びだけを送る。下書き→画像の順に行ロックして、投稿と画像を1つのトランザクションで保存する。下書きIDを投稿IDとして使い、同じ内容の再送は同じ投稿を返す。
5. 投稿済みの画像は /media/{画像ID} からストリームで配信する（private, no-store・nosniff）。DBで公開中の投稿に属することを毎回確認する。

回収

• 添付の解除・キャンセル・下書きの期限切れでは、予約を破棄して実体の削除を予約する。トークンの有効期間中は遅れて届くアップロードで実体が再生成され得るため、削除はトークンの期限後に行う。
• 画像行が消えると（アカウント削除のCASCADEを含む）、トリガーが同じトランザクションで削除予約を作る。配信は直ちに404になる。
• pnpm media:cleanup（--test でテスト用）とCronが同じ回収処理を実行する。期限切れの下書きの破棄、時期が来た削除予約の実行、管理パス配下の24時間以上古い孤立した実体の削除を行う。Blobの削除に失敗した予約は残して再試行する。

注意

• 本文の「空なら画像が必要」という制約は、コミット時に検査する遅延制約（constraint trigger）で実装している。postgres.jsの自動コミットの単発SQLでは、この制約の失敗が呼び出し元に返らない（行はロールバックされる）。投稿を書き込む処理は必ず明示的なトランザクション（sql.begin）で行う。

ツイート編集ダイアログの仕様メモ

• 004-edit-tweet.sql を pnpm db:migrate（開発）・pnpm db:migrate --test（テスト）で適用する（003 の後）。投稿の版（tweets.revision）、下書きの用途（tweet_drafts.purpose = create / edit・対象の投稿・準備時の版）、画像の位置の一意制約の遅延化、削除予約の時刻の変更を含む。
• 編集を始めると、サーバーで所有者を確かめ、DBの現在の内容と版を記録した編集用の下書きを作る。作成用の確定（publish）は編集用の下書きを受け付けない。
• 確定は対象の投稿→下書き→画像・予約の順にロックし、版が準備時と同じときだけ、本文・画像の解除（削除予約）・保持画像の位置の詰め直し・新規画像の追加を1つのトランザクションで行う。保持する画像は行を作り直さないので、画像ID・URLは変わらない。版が違えば何も変えずに競合を返す。
• 内容が実際に変わったときだけ版と updated_at を進める（何も変えない保存は成功するが、版・編集日時は変わらない）。投稿日時（created_at）は変えないので、一覧の並びとカーソルは変わらない。
• 同じ下書き・同じ入力の再送は成功済みとして扱う。使わなかった新規画像は確定時に破棄し、閉じた場合は編集用の下書きの新規画像だけを破棄する（元の投稿の画像は残る）。
• 画像行の削除による削除予約は、その画像のトークンの期限（最大15分）以降にする（アカウント削除経由でも同じ）。有効なトークンで同じパスに実体が作り直される隙間を作らないため。
• 成功しても画面は移動しない。revalidatePath で表示を更新し、成功の通知はルートlayoutのダイアログ管理（TweetComposerProvider）が出す。

ツイート削除の仕様メモ

• migrationの追加はない（003・004 の適用が前提）。
• 本人の元投稿のカードだけに「…」→「削除する」を出す（編集と同じ判定。リツイートしただけの人には出さない）。開くときにサーバーで所有者を確かめるだけで、何も変更しない。削除は確認ダイアログの「はい」の送信時だけ行う。
• 確定のたびにセッションの利用者を確認し、確認を開いたときの利用者（expectedActorId）と照合する。食い違えば誰の投稿も削除しない（Aで開いてBに切り替えた場合）。未ログインならログイン画面で「ツイートを削除するにはログインしてください」を表示する。
• DBでは、投稿をロックしてから所有者を確かめ、DELETE ... WHERE id AND owner_id を1つのトランザクションで行う。画像・リツイートはCASCADE、画像の実体の削除予約は既存のトリガーが同じトランザクション内に作る。
• 投稿まわりのロックは「投稿→下書き→画像・予約」の順にそろえる（削除・編集の準備・編集の確定・アカウント削除）。削除時の ON DELETE SET NULL は投稿のロック後に下書きを更新するため、編集の確定も、下書きから対象を読んだうえで投稿→下書きの順にロックする。下書きを先にロックする方式では、ロック後に作られた編集用の下書きでデッドロックが起き得た（順序を固定した結合テストで確認）。
• 削除のActionからBlobのAPIは呼ばない。画像のURLは画像行がなくなった時点で404になり、実体はトークンの期限以降に pnpm media:cleanup で消える。開いていた編集用の下書きは対象がNULLになり、その新規画像は下書きの破棄・期限切れで回収される（無関係な投稿・画像は残る）。
• 既にない投稿は削除成功と区別し「このツイートは既に削除されています」と通知して閉じ、一覧を再取得させる。他人の投稿・障害は理由を表示して削除しない（障害時は「はい」で再試行できる）。
• 成功しても画面は移動しない。revalidatePath で / と全プロフィールを更新し、同じ元投稿のカード・リツイートをすべて消す。成功の通知はルートlayoutの TweetComposerProvider が1回だけ出し、フォーカスは一覧の見出しへ移す。
• ダイアログを閉じた後のフォーカス（起動元のボタン・削除後は一覧の見出し）は、再取得で一覧が読み込み表示に置き換わっていても、DOMの変化で再表示・有効化を待って移す（固定時間は待たない）。戻した直後に作り直されたら新しい要素へ移し直し、利用者が先に別の場所へ移した・操作した場合は奪わない。
• 確認結果（2026-10-26、テスト専用DB・Blob）: 単体・UI 673件、結合 110件、E2E 58件（削除の6件は連続2回成功）、pnpm build 成功。削除後の pnpm media:cleanup --test は、トークンの期限前は実体を残し、期限後に削除した投稿の画像だけを回収した（残す投稿の画像は残り、再実行も成功）。

お気に入りの仕様メモ

• 005-create-favorites.sql を pnpm db:migrate（開発）・pnpm db:migrate --test（テスト）で適用する（004 の後）。ER図のLike（相手からも見える「♡」）とFavorite（自分専用の保存）は別機能で、Favoriteは自分専用の保存としてLikeとは独立して実装した（ER図の executor_id は実装に合わせて user_id とした）。
• カードの右端の旗のようなbookmarkアイコンで、元投稿を登録・解除する（リツイートのカードでも対象は元投稿、自分の投稿も保存できる）。アクセシブル名は「お気に入りに追加／お気に入りを解除」、状態は aria-pressed。押したら次の状態を明示して送り、トグルにしない。
• 登録・解除は利用者・投稿を FOR KEY SHARE でロックしてから行う。保存済みへの登録は保存日時・UUIDを変えず（ON CONFLICT DO NOTHING）、解除済みへの解除も成功。解除後の再追加は新しい保存日時で先頭に出る。競合中に関連が消えた場合の外部キー違反だけを「対象なし」に変え、他のDBエラーは成功扱いしない。
• 未ログインでは移動せず「ログイン中のみお気に入りに設定できます」を3秒表示する。画面を表示した利用者（expectedActorId）と現在の利用者が違えば、誰の保存も変えない。失敗時は表示中の状態を変えずに理由を通知する（通知はルートlayoutの ActionFeedbackProvider）。処理中は押せない。
• /favorites はログイン中の本人だけの一覧（未ログインは /login、URLのuserIdは無視）。保存した日時の降順 (created_at, id) で20件ずつ、元投稿の現在の本文・画像・作者を1ページ1回のSQLで表示する。カーソルは本人のUUIDと一覧の種類に結び付け、他人のカーソルは不正として扱う。空・不正なカーソル・取得障害を区別し、解除して空になったページにも先頭へのリンクを出す。
• タイムライン・プロフィールの各カードの保存状態は、ページの行を選んだ後に閲覧者本人のUUIDで判定する（プロフィールの対象者とは取り違えない。未ログインは常に未保存）。保存件数や他人の保存一覧は表示しない。
• 投稿の削除・作者の退会で一覧から消え、自分の退会で自分の保存行も消える（CASCADE）。保存の操作で元投稿の画像を複製・削除しない。編集・削除・プロフィール編集・アカウント削除の成功時にも /favorites を再取得させる。
• 確認結果（2026-10-26、テスト専用DB・Blob）: 単体・UI 732件、結合 122件（後から追加した画像を複製・削除しないことの1件は単独で成功）、E2E 66件（お気に入りの8件は連続2回成功）、pnpm build 成功。開発用DB（Neonの開発ブランチ）にも005を適用済み。

投稿ダイアログの通信失敗の仕様メモ

• migration・ロック順・application/DBの契約の変更はない。作成・編集・削除のダイアログと、それを開く準備のAction呼び出しだけを app/ui/tweets/invoke-dialog-action.ts で包む。
• Action呼び出し自体のreject（通信の切断・応答の読取失敗など）は、画面をエラー境界へ置き換えずに失敗結果（NETWORK_ERROR、クライアントだけが作るコード）へ変える。redirect()・notFound() 等のNext.jsの制御例外は導入版の公開API unstable_rethrow で同じ値のまま再throwし、投稿成功後の /・未ログイン時の /login への移動を妨げない（unstableなAPIへの依存はこのファイルだけ）。
• サーバーで確定して応答だけを失った場合もあるため、「変更されていない」とは案内せず「通信に失敗し、処理結果を確認できませんでした。入力を変更せず、もう一度お試しください」をダイアログ内に出し、「通信に失敗しました。もう一度お試しください」を3秒表示する（失敗のたびに出し直す。生のエラー内容は表示しない）。
• ダイアログは閉じず、本文・下書きID・保持する既存画像・新規画像の予約ID・削除の対象と利用者を保つ。下書きの破棄・画像の解除はしない。再試行は利用者が同じボタンを押したときだけで、同じ下書きのまま送る（新しい下書きを作り直さない）。送信中は本文を変更できない（作成も readOnly）。
• 確定済みだった場合の再送は既存の判定に従う。作成は同じ下書き・同じ内容の再送として同じ投稿を返して / へ移動し、編集は再送として成功（版・画像・削除予約を増やさない）、削除は「このツイートは既に削除されています」として閉じて一覧を更新する。
• 開く準備で通信が失敗したら開かずに同じ文言を画面上部に3秒表示し、自動で消す。失敗のたびに通知を出し直し、その時点から3秒表示する。通知の表示中・表示後ともに再び押せる。準備で作られたかもしれない下書きはUUIDが分からないため推測で破棄せず、期限切れの回収に任せる。
• 2026-10-28の仕様変更：準備時の通信エラー通知を3秒で自動消去する要件を追加（app/ui/tweets/tweet-composer.tsx）。サーバーが返した準備の失敗の理由（「このツイートは削除できません」など）は対象外で、次の準備操作まで表示する。

いいねの仕様メモ

• 006-create-likes.sql を pnpm db:migrate（開発）・pnpm db:migrate --test（テスト）で適用する（005 の後）。ER図のLike（executor_id / tweet_id / created_at）のとおり、Favoriteとは別の twitter.likes に保存し、利用者・元投稿ごとに1行。
• いいね（♡）は相手からも見える反応、お気に入り（右端の旗）は自分専用の保存で、データ・ボタン・一覧を共有しない。片方の操作でもう片方の行・件数・一覧は変わらない。
• 各カードのハート（未登録は輪郭、登録済みは塗りつぶし）で元投稿へのいいねを登録・解除する。リツイートのカードでも対象は元投稿、自分の投稿にもいいねできる。アクセシブル名は「いいねする／いいねを取り消す」、状態は aria-pressed、件数は公開（読み上げは「いいねN件」）。押したら次の状態を明示して送り、トグルにしない。
• 登録・解除は利用者を FOR KEY SHARE、元投稿を FOR NO KEY UPDATE でロックして（お気に入りと同じ利用者→投稿の順）同じ元投稿への操作を直列化し、最後に件数を読み返す。登録済みへの登録はUUID・日時を変えず、解除済みへの解除も成功。解除後の再登録は新しい日時で公開一覧の先頭に出る。投稿の本文・日時・版は変えない。競合中に関連が消えた場合の外部キー違反だけを「対象なし」に変え、他のDBエラーは成功扱いしない。
• 未ログインでは移動せず「ログイン中のみいいねできます」を3秒表示する。画面を表示した利用者と現在の利用者が違えば、誰のいいねも変えない。失敗時は状態・件数を変えずに通知し、Action呼び出し自体のreject（通信の失敗など）も同様に通知して再試行できる。Next.jsの制御例外は invokeDialogAction で同じ値のまま再throwする。処理中は押せない。
• プロフィールの ?tab=likes（「いいね」タブ）は、その利用者がいいねした元投稿の公開一覧で、未ログインでも閲覧できる。いいねした日時の降順 (created_at, id) で20件ずつ、元投稿の現在の本文・画像を表示する（投稿の日時は変えず、ホームの新しい出来事にもしない）。カーソルは対象者のUUIDとlikesタブに結び付け、投稿・リツイートのカーソルとは混ぜない。
• 各カードの本人状態（いいね・お気に入り）は閲覧者について判定し、公開いいね一覧でも対象者のお気に入り状態は返さない。画像・件数・本人状態はページの行を選んだ後に集約し、1ページ1回のSQLのまま行や件数を掛け合わせない。
• 投稿の削除・作者の退会で関連するいいねが消え、いいねした人の退会ではその人のいいねだけが消える（CASCADE）。
• 確認結果（2026-10-27、実装worktree）: 単体・UI 847件、型チェックPASS。006の適用・結合（test/integration/postgres-likes.test.ts ほか）・E2E（test/e2e/likes.spec.ts）・pnpm build はコーディネーターの確認待ち。

リツイートの仕様メモ

• migrationの追加はない。既存の twitter.retweets（executor_id / tweet_id の一意制約）を使い、利用者・元投稿ごとに1行。引用リツイートは扱わない。
• 各カードの「リツイートする／リツイートを解除」（aria-pressed、読み上げは「リツイートN件」）で元投稿のリツイートを登録・解除する。カードの並びはリツイート→いいね→お気に入り（右端の旗）。リツイートのカードで押しても対象は元投稿のUUIDで、表示中のリツイート行やその実行者は送らない。押したら次の状態を明示して送り、トグルにしない。
• 自分の投稿のリツイートも許可する（資料に制限がないための補完仕様）。解除できるのは自分のリツイートだけで、作者でも他人のリツイートは消せない。
• 登録・解除は利用者を FOR KEY SHARE、元投稿を FOR NO KEY UPDATE でロックして（いいね・お気に入りと同じ利用者→投稿の順。投稿を先にロックすると退会のCASCADEとデッドロックする）同じ元投稿への操作を直列化し、同じトランザクションで件数を読み返す。登録済みへの登録はUUID・日時を変えず、タイムラインの順位も上がらない。解除済みへの解除も成功。解除後の再実行は新しいUUID・日時となり、タイムラインの先頭側へ出る。元投稿の本文・日時・版・画像、お気に入り・いいねは変えない。競合中に関連が消えた場合の外部キー違反だけを「対象なし」に変え、他のDBエラーは成功扱いしない。
• 未ログインでは移動せず「ログイン中のみリツイートできます」を3秒表示する。画面を表示した利用者と現在の利用者が違えば、誰のリツイートも変えない。失敗時は状態・件数を変えずに通知し、Action呼び出し自体のreject（通信の失敗など）も同様に通知して再試行できる。Next.jsの制御例外は invokeDialogAction で同じ値のまま再throwする。処理中は押せない。
• 成功時はメイン・プロフィール・お気に入りを再取得し、現在のURL・カーソルのまま同じ元投稿の全カードの状態・件数を更新する。解除で自分のリツイートのカードは消えるが、元投稿や他人のリツイートのカードは残る。「フォローのみ」は従来どおりリツイートした人で判定する。自分のリツイートは含まない。
• 各カードの本人状態（リツイート・いいね・お気に入り）は閲覧者について判定し、未ログインはfalse。件数・本人状態はページの行を選んだ後に集約し、1ページ1回のSQLのまま行や件数を掛け合わせない。
• 確認結果（2026-10-27、実装worktree）: 単体・UI 71ファイル・932件、型チェックPASS。結合（test/integration/postgres-retweets.test.ts）・E2E（test/e2e/retweets.spec.ts）・pnpm build はコーディネーターの確認待ち。

フォローの仕様メモ

• migrationの追加はない。既存の twitter.follows（follower_id / follow_id の一意制約、自己フォロー禁止のCHECK）を使い、方向ごとに1行。鍵アカウント・承認・ブロックは扱わない。
• 他人のプロフィールのヘッダーに「フォローする／フォロー解除」（aria-pressed）を表示し、以前の操作できない「フォロー中」表示を置き換えた。自分のプロフィールには出さない。対象は表示IDではなく表示中のプロフィールのUUIDで送るので、表示後に相手がIDを変えたり、旧IDを別人が使ったりしても、表示した相手を操作する。押したら次の状態を明示して送り、トグルにしない。
• 自分自身のフォローは、applicationでUUIDを正規化して比較し（大小文字違いを含む）DBを呼ばずに拒否する。DBのCHECKでも拒否される。
• 登録・解除は1トランザクションで、本人と対象の users 行をUUID順に FOR UPDATE でロックしてから行う（相互フォローの同時操作で逆順にロックしない。退会とも直列化する）。登録は ON CONFLICT (follower_id, follow_id) DO NOTHING で、登録済みへの登録は関係のUUID・日時を変えない。解除は follower_id = 本人 AND follow_id = 対象 だけを消し、逆方向の行には触れない。解除済みへの解除も成功。解除後の再登録は新しいUUID・日時となり、一覧の先頭に出る。競合中に消えた利用者の外部キー違反だけを「対象なし」（本人なら未ログイン）に変え、他のDBエラーは成功扱いしない。
• 未ログインでもボタンを表示し、押すと移動せず「ログイン中のみフォローできます」を3秒表示する（書き込まない）。画面を表示した利用者と現在の利用者が違えば、誰の関係も変えない。失敗時は状態を変えずに通知し、Action呼び出し自体のreject（通信の失敗など）も同様に通知して再試行できる。Next.jsの制御例外は invokeDialogAction で同じ値のまま再throwする。処理中は押せない。
• 成功時はメイン・全プロフィール・お気に入りを再取得する（対象のフォロワー数、本人のフォロー数、両側の一覧、別のページでの状態が変わるため、対象者のページだけに絞らない）。現在のURL・タブはそのまま。「フォローのみ」はフォロー中の人の出来事だけで、自分の投稿・リツイートは含まない。フォロー中の人が他人の投稿をリツイートした出来事は含む。
• フォロー・フォロワー一覧の各行にはボタンを置かない。行から相手のプロフィールへ移動して操作する。
• 確認結果（2026-10-27、実装worktree）: 単体・UI 75ファイル・989件、型チェックPASS。結合（test/integration/postgres-follows.test.ts）・E2E（test/e2e/follows.spec.ts、変更した test/e2e/profile-screen.spec.ts）・退会時の両方向CASCADE・pnpm build はコーディネーターの確認待ち。

ログアウトの仕様メモ

• 共通ナビと自分のプロフィールの「ログアウト」から、現在のブラウザの認証だけを終了する。POSTのフォームとAuth.jsの signOut({redirect:false,redirectTo:'/login'}) を使い、認証Cookieの削除はAuth.jsに任せる。成功後は /login に移動し「ログアウトしました」を3秒表示する。通知は一度だけ消費し、再読み込みでは出さない。
• 操作時の auth() のUUIDと画面表示時のUUIDを照合し、別の利用者に切り替わっていたら、その利用者をログアウトさせない。認証そのものが失敗したときは処理せず、既に匿名の場合は残っているCookieを清掃できる。ユーザーDBの実在確認やDB接続をログアウトの前提にしない。
• 投稿・画像・いいね・お気に入り・フォロー・リツイートは変更せず、別のブラウザのログインも終了しない。成功時はルートlayoutの表示キャッシュを無効化し、本人限定の画面は既存の認証ガードで保護する。
• 投稿ダイアログの準備・表示とログアウトは、ルートProviderの同期的なロックで排他にする。ログアウト中は新しいダイアログを準備せず、失敗時とボタンのアンマウント時に自分のロックだけを解放する。古い画面から遅れて返った失敗は、新しい画面のロックを解除せず、通知もしない。
• 入力・認証・通信の失敗ではその場で説明を表示し、再試行できる。Next.jsの正常なredirectを通信失敗へ変換しない。migrationの追加はない。

残り主要機能の全体確認（2026-10-27）

通信失敗対応、公開いいね、リツイート操作、フォロー操作、通常ログアウトを実装し、既存の登録・編集・削除・お気に入りと合わせて検証した。単体/UI1011件、結合164件、全E2E105件、型チェック、本番ビルドが成功。いいね・フォロー・ログアウトは全体後の22件の再実行でもすべて成功した。詳細は 全体計画 を参照。

006はテストDBと開発用DBに適用済み。本番DB・本番Blobへの反映と、デプロイ環境での5MiB画像確認はリリース時の別作業として残る。