voicestudio-maintainer

VoiceStudio のメンテナンス

最初に、対象リポジトリの AGENTS.md、CLAUDE.md、コントリビューションガイド、リリースドキュメントを読んでください。これらのポリシーは、この一般的なワークフローに優先します。このスキルをインストールしても、マージ、リリース、イシューのクローズ、コントリビューターへのメッセージ送信が許可されるわけではありません。

トリアージと実装

• 報告された修正を重複して行わないよう、現在のコードと既存の PR を確認してください。問題を解決するコントリビューターの作業があれば再利用し、クレジットを明記してください。
• 可能であれば、報告された動作を再現してください。確認済みの不具合と診断を区別し、重要な制約があれば PR に記録してください。
• 原因を、完全な修正となる最小限の変更で解決してください。再発する可能性がある場合は、観測可能な動作をテストしてください。ソーステキストのアサーションをエンドツーエンドテストと取り違えないでください。
• ローカルの変更を保持してください。ブランチの切り替えによってローカルの変更に影響する場合は、独立したワークツリーを使用してください。
• 作業を再実行する前に、既存の CI 失敗とレビュアーのコメントを読んでください。再試行する前に失敗の原因を診断し、パイプ処理の成功によって失敗したゲートを隠さないでください。
• ユーザー向けドキュメントと必要な翻訳を実装に合わせてください。

レビューと許可された取り込み

現在の main に照らして、現在の差分、ボットからの指摘、必須チェックをレビューしてください。取り込み前に、PR ブランチで重要な指摘に対応してください。先にマージして後から対応すると約束してはいけません。リポジトリのポリシーに従って古くなったブランチを更新し、コントリビューターのコミットを保持してください。

許可されたマージの前に、必須チェックがすべて成功していること、head が変更されていないこと、PR をマージできる状態であることを確認してください。取り込み後は、main 自体の実行結果を確認し、リグレッションがあれば直ちに調査してください。確認の成功を捏造せず、残っているブロッカーを報告してください。

リリースの準備

CI やパッケージングの準備と公開は別の作業です。許可がない限り、タグ付け、バージョンの更新、公開の有効化、リリースの作成を行わないでください。

リポジトリで正式に使われているバージョン情報の参照元、変更履歴の形式、対応プラットフォーム、配布チャネルに従ってください。依頼された範囲が公開を伴わない場合は、公開せずにパッケージングとワークフローを検証してください。許可されたリリースの後は、実際の成果物、リリースノート、アップデータのメタデータ、依頼されたレジストリチャネルを確認してください。ビルドの成功だけでは、配布が完了した証明にはなりません。

コミュニケーション

結果と根拠を最初に伝えてください。コントリビューターによる具体的な作業を明記してください。古いという理由だけで古いイシューをクローズしたり、実際には得られていない報告者の確認を得たと主張したりしないでください。許可を得てイシューをクローズする場合は、解決内容と、再開が妥当となる根拠を伝えてください。

VoiceStudio 固有の対応方針

debpalash/VoiceStudio をメンテナンスする際は、古いアーキテクチャの想定ではなく、現在のルールを参照してください。

• Electron の開発とパッケージング：electron/README.md、electron/package.json、.github/workflows/。
• バックエンドのコントラクト：実行中の /openapi.json、backend/api/、対象を絞ったテスト。
• リリースチャネルとバージョン管理：docs/RELEASING.md と CLAUDE.md。修正依頼からバージョン更新を決めつけないでください。
• マージ前に CodeRabbit/Greptile からの指摘と必須 CI を確認してください。マージ後は main の CI に従ってください。
• ローカル優先の動作、クロスプラットフォーム対応、モデルのインストールに対する同意、合成音声の明示、ローカライズ要件を維持してください。

現在の開発コマンド

リポジトリのルートから実行します。

bun install
bun run setup:api        # prepare the source Python runtime explicitly
bun run dev              # Electron + supervised backend
bun run typecheck        # Electron main, preload, and renderer
bun run test             # Electron tests
bun run check:electron   # types, tests, build, packaging contract
bun run dist             # local installers; publishing disabled

electron/src/main/ はライフサイクル、IPC、ネイティブヘルパー、バックエンドの監視を担当します。 electron/src/preload/ はレンダラーのブリッジを公開し、electron/src/renderer/src/ には React アプリが含まれます。特権を要するファイルシステムやプロセスの処理はレンダラーに置かないでください。 electron/src/shared/ にはブラウザビルドと共有するモジュールが含まれます。実行可能なアプリではありません。 backend/ は共有の Python API を提供し、native/desktop-bridge/ はネイティブ機能を提供します。frontend/ に出力されるのはブラウザビルドのみです （bun run build:web → frontend/dist/。Docker ではバックエンドが配信します）。ブランディングの整理を理由に、 内部の omnivoice パッケージ、環境キー、データパスを変更しないでください。

Electron が唯一のデスクトップアプリ兼ウェブ UI です。Tauri シェルは削除済みのため、復元しないでください。 最終版 v0.5.3 の Tauri アップデーター用フィードは変更不可の互換性アセットです。また、古い Tauri インストールからの移行については docs/electron-migration.md を参照してください。 アーティファクトのみのパッケージングのリハーサルには electron-build.yml を使用し、 その結果を Windows x64、Linux、macOS Intel、macOS Apple Silicon で確認してください（Windows ARM64 は実験的な対象であり、失敗しても作業を妨げない場合があります）。 パッケージングのテストにリリース／公開ワークフローを実行しないでください。署名、アップデーターの移行、インストールの成功は、ビルドの成功とは別個に確認する必要があります。 アプリのバージョンはルートの package.json に設定されており（pyproject.toml と backend/core/version.py にも反映されています）、明示的なバージョン更新タスクがない限り変更しないでください。

バックエンドのテストには、リポジトリの CI 依存関係と、空の一時的な HF_HUB_CACHE を HF_HUB_OFFLINE=1 と併せて使用してください。開発者がインストールしたモデルによって、フィクスチャの不足が隠れないようにしてください。 編集時には対象を絞ったテストを実行し、変更を取り込む前に必須の全チェックを実行してください。既存の CI 失敗は引き続きブロッカーであり、免除されたことを意味するものではありません。