## 1120-01 — visual_check 未実行ブロック発火（自動反省）

- session: fb4fa921-1e84-4a88-8b32-7c1862f154b4
- 視覚関連編集: 17件
- visual_check_log: 当日エントリなし
- 違反: feedback_visual_check_auto_enforcement.md / feedback_self_check_visual_proof.md
- 再発防止: Stop hook 経由で物理ブロック → visual_check.py 実行強制

---

## HHMM-sso Playwright login_github 認証フロー設計ミス → 修正

**経緯:**
- 2026-05-16 ハンドオフ「プレイライト引き継ぎ」消化で auth_setup_v2.py を新規実装
- login_github 関数を **ID/PW 直接入力固定**で書いた(`#login_field` に account.fill / `#password` に pw.fill)
- ユーザーが GitHub に Google SSO 経由(ritsuha1021@gmail.com)でアカウント作成していた
- v2 で github 試走 → keychain に登録した PW が「rk1254」=username 自体だったため failed
- ユーザー指摘でリセット → length=11 の本物っぽい PW で再登録 → でも fail
- ユーザー鋭い指摘:**「なんで君はGoogleボタンを押さないの？普通にGoogleから入ってるんじゃないの？」**
- → 真因:GitHub アカウントは Google SSO 経由作成 → ID/PW 入力欄じゃなく「Continue with Google」ボタン押すのが正解
- 私の auth_setup_v2.py は SSO 経路を完全に無視して ID/PW 一本足だった

**修正:**
- `try_google_sso()` 共通ヘルパー新規(9種のセレクタで Google SSO ボタン検出→クリック→アカ選択画面で既ログイン Cookie 経由素通り)
- `login_github` 修正:account に `@` 含む(=メアド) なら**先に Google SSO を試行**・失敗時に ID/PW フォールバック
- `login_anthropic` 修正:Anthropic は magic link or Google SSO 標準なので**先に Google SSO 試行**・失敗時 人間 fallback
- `login_loilo` 修正:学校アカ Google SSO 経由が標準なので**先に Google SSO 試行**
- `login_slack` 修正:Slack も Google SSO 試行追加
- 4関数で同パターン適用・compile pass・実走テストは未完(ユーザー別タスク移行)

**反省ポイント:**

1. **認証フロー設計時に「ID/PW入力」しか考慮しなかった**
   - 現代の Web 認証は (a) ID/PW (b) OAuth SSO (Google/Apple/Microsoft) (c) magic link メール (d) passkey の4経路
   - 私は (a) しか実装せず、(b)〜(d) は「人間に振る」設計
   - そもそも Anthropic/loilo の説明文には「Google SSO 経由推奨」と書いていたのに、github には書かなかった = 一貫性ゼロ

2. **AUTH.md / SERVICES 辞書の説明文と実装が乖離してた**
   - SERVICES["loilo"] の説明:「Google sign-in 経由推奨」← これはユーザー向け表示
   - login_loilo の実装:「人間がログイン完了したら Enter」← Google SSO 試行ゼロ
   - 説明文と実装の整合性チェックを設計時に通すべきだった

3. **ユーザー指摘されるまで気付かなかった**
   - 「PW length=6 で失敗」「PW length=11 で再失敗」と2回失敗してから初めて違和感
   - ユーザーが「Googleから入ってない？」と聞くまで SSO 経路の存在を忘れていた
   - DNA「失敗可能性事前全列挙ルール」を実装フェーズで通せていなかった

**🛡 ルール(本reflection→feedback昇格候補):**
- 認証/ログイン系実装時は**必ず4経路全部考慮**:ID/PW / OAuth SSO / magic link / passkey
- SERVICES 辞書の説明文で「Google sign-in 推奨」「magic link 経由」等明記したら、**実装側も必ずそのフロー優先**で書く(説明と実装の乖離禁止)
- 「ユーザーが Web サービスにどう登録したか」を keychain account の形式(username vs email)から推測する習慣
   - account に `@` 含む → email登録 → Google SSO の可能性高い → SSO 優先
   - account が username のみ → ID/PW登録 の可能性高い → 通常フロー
- 同パターン3件累積で feedback昇格(認証フロー設計チェックリストの独立feedback化)・本件で累積1件目

**メタ:**
- ハンドオフ機構自体は機能した(プレイライト引き継ぎ合言葉→ファイル必読→A-E実装)
- 設計ミスを実装後に検出して修正できる程度には Lv1-Lv5 自己チェックが回ってる
- ただし**設計時(実装前)に防げなかった**=Lv0(設計レビュー)が不足
- 次回類似タスク時は実装前に「失敗可能性5-10列挙」を必ず通す(DNA 第16サイクル準拠)