core-qa-process

name	core_qa_process
description	CSW (Rust + Tauri v2) の QA・検証プロセスと継続的改善のルールを定義するスキル。コード変更の完了報告前、PR を出す前、機能や修正を「できた」と言う前に発動し、検証順序とエビデンス必須の原則を強制する。

＃ QA・検証と継続的改善

CSW (Rust + Tauri v2 / macOS) で開発した機能・修正を品質低下なく本番 (DMG リリース) に乗せるための検証プロセスと、AI 自身が同じミスを繰り返さないための継続的改善ルール。

[!CAUTION] AI は「できた」「PASS」と報告する前に、自分でエビデンスを確認する義務がある。 core/CLI 変更ならコマンド実行結果、GUI 変更ならアプリ起動 + WebView の挙動を一次情報として確認する。サブエージェントの「PASS」報告を鵜呑みにしてはならない。エビデンスなき PASS は虚偽報告と同等。

1. 検証の固定順序 (厳守)

コード変更後は必ずこの順序で検証する。前段が落ちたら次に進まず、その場で直す。

1. cargo fmt --check
2. cargo clippy --workspace --all-targets -- -D warnings
3. cargo build --workspace
4. cargo test --workspace
5. (GUI 変更時) cargo tauri dev でアプリ起動 + WebView devtools 確認

• fmt → clippy → build → test → アプリ起動 の順を崩さない。整形・lint・型/ビルドの機械的エラーを先に潰してから、振る舞いの検証 (test / 実機) に進む。
• clippy は -D warnings で警告ゼロが合格条件。#[allow(...)] で抑止する場合は理由を // ALLOW: コメントで明記する (modern-rust-workflow 参照)。
• cargo fmt --all は実際に整形する操作。検証は破壊しない cargo fmt --check で行い、差分があれば整形してから再検証する。

[!IMPORTANT] cargo はローカル環境で使えないことがある。その場合 CI が検証パスの本体になる。 PR を push し、CI の Test (cargo test --workspace --exclude csw-desktop = core+cli) と Build (cargo build --workspace = desktop 含む全クレート) の結果ログを一次エビデンスとして確認する。CI のグリーンを確認せずに「通った」と書かない。

2. クレート別の検証観点

クレート	検証手段	観点
crates/core (csw-core)	cargo test --workspace / CI Test	ロジック・プロファイル隔離・Keychain (MockKeychainProvider) のユニット/結合テスト
crates/cli (csw)	cargo test + 実コマンド実行	引数解釈・exit code・標準出力/エラー出力の文言
crates/desktop (csw-desktop)	cargo build --workspace (CI Build) + cargo tauri dev	コンパイル可否 (CI Test からは除外) + 実機でのトレイ/設定 UI 挙動

• csw-desktop は CI の Test ジョブから除外されている。desktop のビルド健全性は Build ワークフロー (全ワークスペースビルド) で、振る舞いは cargo tauri dev の実機確認でしか担保できない。 test が緑でも desktop が壊れていないことの証明にはならない点に注意。

3. GUI 変更時の実機確認 (The QA Agent 視点)

GUI (トレイ / 設定ウィンドウ) を変えたら、cargo tauri dev でアプリを起動し、以下を自分で確認する。

• 見た目の確認: 期待した UI が実際に描画されているか (スクリーンショットを取り、自分で Read で開いて確認する)。
• WebView devtools のコンソールエラーチェック: WebView 内で右クリック → Inspect Element (または開発ビルドの devtools) を開き、Console にエラー/警告が出ていないか確認する。フロントエンドの例外は build/test では検出されない。
• トレイ常駐の動作: メニュー項目・クリック・プロファイル切替が期待どおり反応するか。
• エビデンスを項目ごとに個別確認する: 複数箇所を一括修正して「全部 OK」と丸めない。1 項目 1 エビデンス。

4. リファクタ・名称変更後の全域確認

名称変更・リファクタリング後は Grep でワークスペース全体 (crates/ / docs/ / website/) を横断検索し、旧語彙・旧 API の残存がゼロであることを確認する。コメント・doc・テスト名・エラーメッセージ・LP の文言まで含めて潰す。

5. 継続的改善とフィードバックループ (義務)

発生した問題を単に直すだけでなく、「なぜ起きたか」「どうすれば AI が同じミスを繰り返さないか」を分析し、規約・スキルへ還元する。

1. 問題解決後の振り返り: 複雑な不具合解決や大規模修正の完了後、得られた知見を抽出する。
2. ルールの言語化: 新たなアンチパターンを見つけたら .agents/skills/ を更新する (または CLAUDE.md に追記)。直す前に「汎用化できる教訓か」を毎回明示的に判断する。
3. 知識の代謝: 定期的にルールを抽象化・圧縮する。SKILL.md は 1 ファイル 80 行以内を目安に保つ。
4. 人間の承認ゲート: 仕様確定 (docs/SPECIFICATION.md)、main へのマージ、#[allow(...)] 追加など不可逆/方針が割れる分岐は、推奨を添えて人間の Approve を求める。
5. 自己進化: 各タスクフェーズの終わりに、検証プロセスの非効率やルールの穴がないか自己評価し、改善案を提示する。

6. 絶対に譲らない原則

• セキュリティ・プライバシー・倫理を利便性と引き換えにしない。 検証を急ぐために Keychain・プロファイル隔離の確認を飛ばさない。
• コマンド出力を切り詰めない。 「…(略)」で要約せず、失敗箇所・テスト結果は全文を確認する。途中で truncate して PASS と判断しない。
• 検証の偽装をしない。 スクリーンショットに修正が反映されていない / サブエージェントの「確認した」を転記しただけ、は虚偽。AI 自身が一次情報を開いて確かめる。

関連スキル

• core_spec_first_development (/spec-first): 仕様合意 → テスト(RED) → 実装(GREEN) → エビデンス付き検証の順序。
• core_bug_fix_protocol (/bugfix): リグレッションテストファースト、プロファイル隔離・並列安全性の検証観点。
• core_pr_review_cycle (/code-review): lint/test 全パス後の PR レビューサイクルとマージ基準。
• modern-rust-workflow: clippy -D warnings・エラーハンドリング・ワークスペース運用の標準。

追記: スキルの実測適用と検証の自走

スキルは読むだけでなく出荷前チェックを実測で通す

該当スキルを一度読んだだけでは適用したことになりません。出荷前に、そのスキルの出荷前チェックリストを 1 項目ずつ、実測の根拠を添えて通します。眺めただけ・既存の成果物に似せただけは通過にしません。

• 編集の頭で当てる節を宣言する: 各編集に着手する前に、その編集に効く具体的な節・ルールを列挙してから書き始めます。「このスキルを読んだ」で済ませず、「§X の○○をこの変更に当てる」と 1 行で明示します。
• テキストは数値と実レンダで確認する: コピー・ドキュメント・UI 文言を変えたら、各行の文字数 (最終行が 2〜3 字の孤立行になっていないか)、見出しの行数、フォントサイズの階層、文体の統一 (丁寧語の完全文かどうか) を、目視の印象ではなく数値または実際のレンダリングで確認します。
• 通した結果を応答に明示する: 「できた」「PASS」と言う前に、どのチェックをどんな根拠で通したかを自分の応答に書き出します。チェック結果の提示がないまま完了を宣言しないでください。

正しい結論に必要な検証は自分の責務 (ユーザーに選ばせない)

正しい結論に当然必要な検証・調査は、ユーザーが決める事項ではなく自分が実行する責務です。変更履歴を当てる、実機で挙動を確かめる、仕様の意味を特定するといった作業を、「これを確認しますか」「どの検証で進めますか」とユーザーに選ばせてはいけません。

• 必要な検証はすべて自分で実行し、結論とその根拠をまとめて提示します。検証の実行可否を問いにして手を止めないでください。
• ユーザーに確認を求めるのは、不可逆な操作や方針が割れる真の分岐 (仕様確定・main へのマージ・#[allow(...)] 追加など) だけに限ります。その確認でも推奨を第一候補に添えます。
• 推奨が出せないときは原因を切り分けます。一次情報を取っていないなら取ってから書く、自分でも決められない不可逆な分岐なら理由を添えて推奨を保留すると明示する。黙って選択肢だけを投げ返さないでください。

「新規/新設」は before/after の比較を取ってから言う

「今回のリリースで新しく入った」「新設された」といった新規性 (novelty) の主張は、before/after の比較根拠を取ってから書きます。現状でその事実を初めて見つけたことは、それが新規であることを意味しません (単なる把握漏れの可能性があります)。

• 変更履歴・リリースノート・旧バージョンの成果物の diff といった一次の比較材料を確認してから新規と述べます。
• リリース時期が近いというだけで、ある機能や挙動をその版のせいにしないでください。タイミングの相関を因果にすり替えないことが原則です。
• 裏が取れないなら正直に書きます。「現在は存在するが、新規かどうかは未確認」と明記し、確認できていない新規性を断定しないでください。
• 「壊れるか」「今どうなっているか」を問われている場合は、現状の検証だけで答えとして十分です。求められていない新規性の主張を足さないでください。