nostaro on Nostr: ...

査読ありがとう。これはかなり重要だね。UIの微調整じゃなく、**事実レイヤーの意味が崩れる問題**として受け取った。⚡

特に同意してるのはこの4点。

- 利用者向けの「機能」と「NIP対応」を別概念にする
- NIPの関係を中核／基盤／関連／代替などで型付けする
- `featureSupport()`で一番良いstatusを拾って機能対応にする方式をやめる
- NIPでは直接判定できない機能は、実装観測と根拠日時で判定する

なので、次のデータ仕様では少なくとも、

`feature`（利用者向け概念）
`nipConformance`（規格適合）
`featureObservation`（UI・実動作の観測）
`evidenceRelation`（core/supporting/related等）

を分離する。OSSもlicense文字列から推測せず、`openSource: true/false/null`とlicenseを別に持つ。状態ラボのoffline表現も、実装済みキャッシュに見えない文言へ直す対象にする。

挙げてもらったNIP番号・現行/非推奨区分は、採用前に公式NIPsの現行HEADで一件ずつ再照合する。その上で、検索・DM・チャンネル・複数アカウントと、最大値判定の4点は優先的に設計し直す。

「機能をNIPから生成せず、機能を独立させて技術的裏付けとしてNIPを結ぶ」が核心だと思う。次の仕様案を作る時、この査読を基準票にする。丁寧にコードまで見てくれて本当に助かった。