reflect

振り返り

Poteto の brainmaxxing reflect（MIT、THIRD_PARTY.md を参照）をベースにしています。このリポジトリには独立したメモリ保管庫はありません。次のエージェントが知っておくべきことはリポジトリ自体にあり、コードと同じようにレビューされます。

プロセス

1. セッションを確認し、次の点を洗い出します。
   • 起きた間違いと、受けた修正。
   • プロダクトオーナーの好み（アプリの動作や表示についての希望）。
   • 得られたコードベースの知識（注意点や、現状の実装になっている理由）。
   • ライブラリやツールの癖（vendor/boring/、Flue、モデルプロバイダー）。
   • スキル（boring-app-template、build-app）の手順、またはアプリのチェックで生じた摩擦。
   • 繰り返し手作業で行っている手順。
2. 些細なことや、すでに記録されていることは省きます（AGENTS.md、docs/、スキルを grep してください）。
3. 各学びを次のルーティングに従って、耐久性のある最小の形で記録します。
4. 変更は現在のブランチまたは新しいブランチに加え、変更内容を伝えます。

ルーティングの順序

1. 構造（principle-encode-lessons-in-structure）：リンタールール（.oxlintrc.json）、アーキテクチャルール（scripts/verify/ARCHITECTURE.json）、ユニットテスト、verify check の手順、エージェントの index.mjs にあるバリデーター、根拠を伴う原則（docs/INVARIANTS.md + scripts/verify/VERIFY.json）、またはモデル（formal/）にできるでしょうか。できる場合はそこに組み込み、説明文は書きません。エージェントが繰り返す間違いは、scripts/verify/ARCHITECTURE.json のルールにします。適用する法則または判断、修正のヒント、ルールが機能することを示す test/unit/architecture.test.mjs のフィクスチャを含めます。さらに望ましいのは、型、単一のヘルパー、制約などによって間違いを不可能にし、ルール自体を不要にすることです。
2. スキル（hachej/boring-stack へのプルリクエスト、skills/<skill>/SKILL.md）：学びがスキルの手順に関するものであれば、その手順を修正します。
3. 機能マップ（docs/verify/<area>.md）：機能の操作に関する注意点を記録します。
4. docs/DECISIONS.md：判断とその理由（「Y だから X を行う。W だから Z は行わない」）を記録します。
5. AGENTS.md：すべてのタスクで、すべてのエージェントが必要とするルールを記録します。簡潔に保ち、詳細はスキルに移します。
6. アップストリーム：@boring/agent、@boring/files、@boring/chat の不足は、issue またはプルリクエストとして hachej/boring-ui-v3 に報告します。vendor/ は編集しません。
7. テンプレート（hachej/boring-app）：新しいアプリすべてに必要な学びです。テンプレートに反映されるよう、その旨を伝えます。既存のアプリには通常のプルリクエストで反映します。

概要

## Reflect summary
- Structural: [rules, tests, checks added]
- Skills: [skill files changed, one line each]
- Docs: [DECISIONS / AGENTS / feature map entries]
- Upstream or template: [issues or PRs to open]