trigger: always_on alwaysApply: false glob:

description: 設計参照・計測・ジャーナル・コミット・ログ確認。調べる場面では search_text を積極的に使う。他ルールは配布ビルド前→distribution-build.md、Issue→issue_management.md。

1. 着手前: タスク着手前に、タスク種別に応じて関連ルールを確認してから作業を開始すること。推測や慣習に頼らず、ルールを読んでから着手する。

   • ジャーナル・アーカイブ → 本ファイル 5–6、CONTRIBUTING の「6. ジャーナル記録」「6.1 ジャーナルのアーカイブ」
   • コミット → 本ファイル 5–7、CONTRIBUTING（pre-commit・protected-files）
   • 配布ビルド → distribution-build.md、docs/specification/05_development_guide.md の本番ビルド
   • Issue 同期・編集 → issue_management.md

2. toolsは.gitignoreだがアクセスは許可されています。

3. 詳細な設計がdocumentsにあるので、改造を計画する際に参照すること。 2.1 search_text を積極的に使う: 事実・仕様・「どこでやってるか」「他プロジェクトのやり方」を調べるときは、grep/read に加えて（あるいは先に）MCP の search_text でインデックスを検索すること。ユーザーが「〜はある？」「〜の方法は？」と聞いた場合も、search_text の利用を検討する。自然な質問（例: 「PDF のソースはどこ」「アーカイブの手順」）で検索するとよい。
4. ソースコードの編集が完了したら、tools/count_loc.cjs と tools/nesting_depth.cjs を使用して計測を行うこと。
5. 計測の結果、ソースコードが600行以上、またはネストが7階層以上のコードについては、リファクタリングを検討すること。
6. コミットする前にジャーナルを書くこと。
7. コミットするときは、そのジャーナルが記録している変更（コード・仕様・計画など）とジャーナルをまとめて add し、同一コミットに含めること。ジャーナルだけ・変更だけのコミットで文脈が分かれることを避ける。
8. コミット直前に tmp/ を確認し、不要な一時ファイル・ログを削除すること。成果物が tmp/ にある場合は適切な場所へ移してからコミットする（.gitignore で tmp/* は追跡外）。
9. 不具合・起動失敗・挙動おかしいときは、つまらない質問をせず必ずログを確認すること。アプリ起動・MCP 待ち・E2E 失敗・indexing が終わらない等は、ターミナル・tauri-driver・バックエンドの標準出力・標準エラーを読んでから原因を判断する。
10. E2E で失敗しているスペックを直すときは、そのスペックだけを npm run test:e2e:spec -- --spec tests/e2e/specs/xxx.spec.js で実行してパッチ当てし、通ったら全件 E2E で再確認すること。test-and-heal も E2E もリトライループは行わない。失敗したら原因を直し（介入し）、再度実行する。
11. テスト実行後の報告: テスト（test:all / test:e2e / test:rust 等）を実行した都度、失敗があった場合は必ずユーザーに報告すること。報告内容: どのコマンドで失敗したか、失敗したスペック名・ケース名、エラーメッセージの概要。成功時も「全テスト成功」と簡潔に伝えるとよい。

絶対禁止: ユーザーから言われたことを意図的に飛ばしたり、省略したり、スキップしたりしないこと。 指示された内容は漏れなく実行する。手順の省略・「とりあえずスキップ」・都合のよい解釈で指示を無視することを禁じる。 異論は言う: 指示に反対・懸念・別案があるときは、黙って従わず理由を添えて伝える。リスクや不具合の可能性がある場合もその場で述べる。

禁止: (a) ルールを確認せずに作業を開始すること。(b) コミット時に journals/ のみ add し、当該変更（コード・仕様など）を add しないこと。(c) 週次アーカイブでリンク一覧だけで済ませ、週サマリー・日付別要約などの本文を書かずに集約元を削除すること。