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

0. **着手前**: タスク着手前に、タスク種別に応じて関連ルールを確認してから作業を開始すること。推測や慣習に頼らず、ルールを読んでから着手する。
   - ジャーナル・アーカイブ → 本ファイル 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

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

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

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