Flutterアプリを自動ビルド・配布できる

コマンドラインから Bridge Server（@ccpocket/bridge）のバージョン bump・CHANGELOG 更新・タグ push を一元管理でき、その後 GitHub Actions が自動で npm publish と GitHub Release を作成します。 前回のリリースタグからの差分コミットを自動解析し、semantic versioning（major / minor / patch）の推奨版を提示してくれるため、バージョン決定の判断が簡単になります。 CHANGELOG を自動で構造化（Added / Changed / Fixed セクション）し、リリースノートの品質を保ちながら手作業を最小化できます。 ローカルで テスト・型チェック・ビルド を実行して検証してから push するため、リリース後の問題を事前に防げます。 Flutter アプリ側の expectedBridgeVersion を同時に更新できるため、Bridge と アプリのバージョンズレによるバナー表示ミスを防げます。 Bridge Server の保守・リリース担当者またはメンテナー バージョン管理・CHANGELOG 更新・リリース自動化を統一したいプロジェクトチーム npm パッケージの semantic versioning を厳密に運用したい組織 GitHub Actions を使った CI/CD パイプラインを構築・運用する開発者 前提: main ブランチで作業中、未コミット変更がないこと。 手順: 1. バージョン確認・差分収集: package.json の現在バージョンを確認し、前回タグからの差分コミット一覧を取得（git log + 条件指定）。 2. バージョン決定: 差分コミットを分析（feat = minor 推奨、fix のみ = patch、破壊的変更 = major）し、AskUserQuestion でユーザーに具体的なバージョン番号を提示・確認。 3. CHANGELOG 更新: packages/bridge/CHANGELOG.md の先頭に新セクション（Added / Changed / Fixed）を追加。 4. バージョン bump: packages/bridge/package.json を更新。 4.5. Flutter 同期: apps/mobile/lib/constants/app_constants.dart の expectedBridgeVersion を同じバージョンに更新（アプリの古いバージョン検出ロジック対応）。 5. ローカル検証: npm run test:bridge / npx tsc --noEmit / npm run bridge:build をすべて実行し pass を確認（失敗時はユーザーに報告・修正待ち）。 6. コミット・タグ: git add → git commit → git push origin main → git tag bridge/vX.Y.Z → git push origin bridge/vX.Y.Z。 7. 完了確認: GitHub Actions (bridge-release.yml) の自動実行を確認。テスト・ビルド・npm publish・GitHub Release 作成が完了したら終了。

新しくリリースされた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()（ロール別ブロードキャスト）で実装します。