trigger: always_on glob:

description: 設計参照・計測・ジャーナル・コミット・ログ確認。他ルールは配布ビルド前→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 でインデックスを検索すること。インデックスにモニタや add_item_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 もリトライループは行わない。失敗したら原因を直し（介入し）、再度実行する。

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