ehagaki-nostr

name	ehagaki-nostr
description	eHagakiのNostrプロトコルまたはNostrデータフローを設計・実装・レビューする際に使用する。NIP、event kind/tag、nostr-tools、rx-nostr、reply/quote/repost、NIP-19/21、relay REQ・購読・AUTH、NIP-07/46、profile、public chat、NIP-94/96/98、Blossomを対象とする。Nostrと無関係なUI、CSS、レイアウト、文言変更には使用しない。

eHagaki Nostr

eHagakiの既存境界と実装済みライブラリAPIを基準に、Nostr関連の変更を設計・実装・レビューする。

調査を開始する

1. 変更に関係するNIPと実際のevent kindを特定する。NIP番号だけで判断しない。
2. 対象となるtag、marker、author、relay hint、contentの意味と必須・任意条件を整理する。
3. rgでeHagaki内の既存builder、resolver、adapter、service、utility、caller、testを検索する。
4. package.jsonを読み、実際に使用中のnostr-tools、rx-nostr、@rx-nostr/crypto、関連ライブラリとバージョンを確認する。古いAPIの記憶だけで実装しない。
5. 変更領域の入口や既存テストを探す必要がある場合は、references/implementation-map.mdを読む。記載と現在のコードが異なる場合は現在のコードを優先する。
6. NIPが定めるwire semantics、nostr-toolsが担うcodec・署名補助、rx-nostrが担うrelay transport・Observable、@rx-nostr/cryptoが担う検証・秘密鍵署名、eHagaki独自の状態・永続化・UI調整を区別する。

既存境界に沿って設計する

1. 既存のbuilder、resolver、adapter、service、utilityがある場合は再利用し、UIやcomponentからNostrライブラリを直接呼ばない。
2. eventの構築とeventの取得を同じ責務へまとめない。
3. discovery、descriptor生成、fetch、cache、renderingを必要以上に結合しない。
4. NIPの仕様とeHagaki固有の仕様を分けて記述する。UI表示からプロトコル仕様を推測しない。
5. nostr-toolsとrx-nostrの責務を混同しない。
6. 一時的な互換処理やフォールバックは、仕様、対応ブラウザ、再現ログ、既存互換契約のいずれかで必要性を示せる場合だけ追加する。
7. 曖昧さがevent semanticsや互換性を変える場合は、推測せずneeds confirmationとして扱う。

取得と購読を検証する

1. event取得ごとに、一回取得か継続購読かを明示する。
2. createRxBackwardReqとcreateRxForwardReqの選択、REQ filter、relay選択、EOSEまたは完了条件、timeout、cancel、unsubscribeの所有者を確認する。
3. Observableやsubscriptionの所有者と終了条件を明確にし、component破棄、scope変更、account変更、成功、失敗、timeoutの各経路で解放する。
4. 複数relayから返る同一eventをevent IDなどの既存キーでdedupeし、同じ状態遷移・永続化・通知を重複実行しない。
5. cacheのfreshness、negative cache、invalidate、retry、同時要求の共有、stale async resultの所有権を確認する。
6. real relayに依存する不安定なテストを追加しない。REQ、packet、EOSE、error、timeoutを決定論的にmockする。

eventとtagを検証する

1. kind、content、tagの順序と重複規則を確認する。
2. NIP-10に関係する変更ではroot、parent/reply、marker、author、relay hintを個別に確認する。
3. quote、public chat、NIP-19 pointerでは、event IDだけでなくauthor hint、kind hint、relay hintの検証とsanitize境界を確認する。
4. eventやtag構築の変更には、順序、marker、root、parent、author、relay hint、重複排除を直接検証するprotocol-focused testを追加または更新する。
5. signerが署名するkindを増やす場合は、NIP46_REQUESTED_PERMISSIONSと関連テストが実際の署名範囲に一致するか確認する。

秘密情報を保護する

1. nsec、秘密鍵、NIP-46 payload、署名要求の本文、認証tokenをログ、fixture、snapshot、screenshot、reportへ残さない。
2. 認証エラーを調査するときも、kind、件数、長さ、状態、秘密を含まない識別情報だけを記録する。
3. 署名者のpubkey、session pubkey、pointerのauthor hint、relay-bound AUTH情報の一致検証を弱めない。

変更とレビューを完了する

1. 最小の既存責務へ変更を置き、無関係なrefactorを混ぜない。
2. protocol semantics、subscription lifecycle、dedupe、cache、securityの観点でdiffをレビューする。
3. Nostr関連の責務、主要ファイル、event kind、tag semantics、対応NIP、関連テストを変更した場合は、references/implementation-map.mdを同じ変更内で更新する。
4. 変更範囲に応じて、対象unit test、component test、Playwright、npm run checkを選ぶ。
5. ブラウザ統合またはユーザー操作を通した一連の挙動が受け入れ条件に含まれる場合はPlaywrightを使う。layout、focus、viewport、clipboard、touchに限定せず、URLクエリ、iframe、ダイアログ操作、アカウント切替、IndexedDBを含むブラウザ内フローも必要に応じて対象にする。
6. protocol semanticsだけの変更にはPlaywrightを追加せず、unit testまたはcomponent testで検証する。
7. 実装変更では狭いテストから実行し、リポジトリ規則に従って原則npm testまで広げる。SvelteまたはTypeScript変更ではnpm run checkも実行する。
8. 実行した検証と結果、実行していない検証と理由を分けて報告する。実行していない検証を成功したと報告しない。