Bridge Server を npm に自動リリースできる

バージョン番号とビルド番号を自動更新：現在のバージョンを確認し、リリース内容に応じてバージョンを bump（例：1.19.0 → 1.20.0）して pubspec.yaml に反映できます。 更新内容を CHANGELOG に自動反映：前回リリース以降のコミットを自動解析し、Added / Changed / Fixed に分類して CHANGELOG を更新できます。 iOS・Android・macOS の任意の組み合わせで同時リリース：プラットフォームを選択するだけで、複数の OS 向けアプリを同時にビルド・署名・配布できます。 GitHub Actions による自動ビルド・署名・配布：タグ push 後、CI/CD パイプラインが自動実行され、TestFlight・Google Play への配布と GitHub Release 作成までが完全自動化されます。 リリース前の自動検証：静的解析とユニットテストをローカルで実行し、問題がある場合はリリースを防止できます。 Flutter アプリの開発・運用チーム：バージョン管理と配布プロセスを統一・自動化したい組織 複数プラットフォーム対応アプリの担当者：iOS と Android を同時リリースする際の手作業を削減したい リリース頻度が高いプロジェクト：毎週・毎日リリースする際の人的ミスを防ぎたい CI/CD パイプラインを構築したい組織：手動ビルド・配布から自動化へ移行したい Flutter アプリのリリースワークフロー全体を自動化します。前提として main ブランチで作業中で未コミット変更がないことが必要です。主な流れは：(1)現在のバージョン確認と差分コミット収集（grep で pubspec.yaml から version を取得、git log で前回タグ以降の差分を確認）→ (2)バージョンとプラットフォームをユーザーに確認（feat/fix コミット有無により minor/patch を推奨、build number は +1）→ (3)CHANGELOG.md を Added/Changed/Fixed で分類更新 → (4)pubspec.yaml の version 更新 → (5)dart analyze と flutter test による検証（失敗時は進まない）→ (6)git add/commit/push と複数プラットフォーム向けタグ打ち（ios/vX.Y.Z+N、android/vX.Y.Z+N、macos/vX.Y.Z+N）→ (7)GH Actions 自動実行（ios-release.yml で TestFlight・GitHub Release、android-release.yml で Google Play）。バージョン形式は X.Y.Z+N（N はビルド番号）です。

新しくリリースされたFlutterバージョンのBreaking Changes・非推奨APIを自動調査し、プロジェクトへの影響を可視化できます。 コードベース内の非推奨API使用箇所を自動検索し、修正が必要なファイルと行数を特定できます。 mise・GitHub Actions・Shorebird・dependency_overridesなどプロジェクト固有の構成それぞれについて、アップグレード時の対応内容をチェックリスト化できます。 Dart SDK制約やパッケージ互換性を確認し、アップグレード実行時の予期しないエラーを未然に防げます。 リリースノート調査から対応タスク作成まで一貫して進め、アップグレード作業の見落としをなくせます。 モバイルアプリ開発チームの技術リード（Flutter定期更新の計画・実行） Flutterエンジニア（新バージョンリリース時の個別対応確認） DevOps・インフラ担当者（mise・CI/CD・Shorebird等の統合管理） プロジェクトマネージャー（アップグレード作業のスケジューリング・見積もり判断） Flutterアップグレードは3フェーズで進みます。フェーズ1（情報収集）: リリースノート（GitHub Issues、docs.flutter.dev、Breaking Changes、Blogから調査）とプロジェクト現状確認（flutter --version、.mise.toml、pubspec.yaml環境）。hotfixの場合はメジャーリリースの Breaking Changes も併せて調査。フェーズ2（影響分析）: Breaking Changes について Grep でコードベース内の使用箇所を検索。mise・GitHub Actions・Shorebird・dependency_overrides・パッケージ互換性（flutter pub outdated）・Dart SDK制約を個別確認。フェーズ3（対応タスクリスト作成）: 必須タスク（.mise.toml更新、mise install、各ワークフロー確認等）と修正対応（Breaking Changes修正、Shorebird doctor確認等）を整理。各フェーズで WebSearch/WebFetch でアップグレード最新情報を参照します。

新機能実装時に NotificationService を呼び出すだけで、ベルアイコン・ドロップダウン・トースト通知が自動表示されます セキュリティ・システム・アクション・情報・警告など、事前定義された6種類の通知タイプから選ぶだけで実装できます 特定ユーザーへの個別通知と、管理者などの特定ロール全体へのブロードキャスト通知（ブロードキャスト通知）が両方対応できます 通知はPostgreSQLに自動永続化され、未読数・既読・削除などの管理が APIエンドポイント経由で自動処理されます 日本語・英語対応で、多言語対応アプリでもそのまま使用できます 新機能実装時に通知周りの複雑な実装を避けたい開発者 ユーザーへのイベント通知を統一的に管理したいプロダクトマネージャー セキュリティアラート・アクション要求など、重要な通知を確実に配信したいシステム担当者 通知センターのUIを共通化して、アプリケーション全体の一貫性を保ちたいデザイナー NotificationServiceは、アプリケーション内での重要なイベントをユーザに通知する統一システムです。通知センター（ヘッダーのベルアイコン）、トースト通知（Sonnerでリアルタイム表示）、DB永続化（PostgreSQL×Prisma）で構成されています。6つの通知タイプ（SYSTEM・SECURITY・ACTION・INFO・WARNING・ERROR）と4段階の優先度（URGENT・HIGH・NORMAL・LOW）があります。ファイル構成は lib/services/notification-service.ts（通知発行）、lib/stores/notification-store.ts（Zustandストア）、lib/i18n/notifications.ts（翻訳）、app/api/notifications/route.ts・[id]/route.ts・read-all/route.ts・unread-count/route.ts（APIエンドポイント）、components/notifications/NotificationBell.tsx他（UIコンポーネント）です。API呼び出しは NotificationService.securityNotify()・systemNotify()・actionNotify()（個別通知）、NotificationService.broadcast()（ロール別ブロードキャスト）で実装します。