カードタイプとカスタムフィールド

Memories のナレッジカードは、既存のタイトル、文書本文、タグ、リンクに加えて、順序付きの型付きフィールドをサポートします。組み込みタイプは note、contact、link、snippet、checklist、event、credential です。タイプは初期フィールドを提供するもので、カードに追加できるフィールドを制限するものではありません。

スキーマ

Content.card_type は省略可能な文字列で、組み込み名またはカスタムテンプレート ID を指定します。Content.fields は順序付き配列です。

{"id":"work-email","name":"Work email","kind":"email","value":"name@example.com"}

名前の変更や並べ替えを行ってもフィールド ID は変わりません。対応する種類は次のとおりです。

null は空を意味します（機密フィールドの場合はマスク済みを意味することもあります）。選択型には、空でなく重複のない options 配列が必要です。他の種類では options を省略する必要があります。カードのフィールドは最大 64 個で、ID は一意、名前と値には上限があります。

暗号化と認可

各リビジョンは、既存の保管庫暗号化で Content 全体を暗号化します。通常カードの機密値は fields から除去され、認証情報本文と同様に、その暗号化リビジョン内の base64url 構造化本文である内部 field_body に保存されます。Base64url 自体は暗号化ではありません。通常の読み取り、一覧、表示操作では field_body は返されず、機密フィールドの値は null として表示されます。文書本文は変更されず、検索可能なままです。機密値は文書本文や検索キャッシュには格納されません。差分には記述子と非機密フィールドだけが表示されます。

意図的な card_fields の実行で reveal: true を指定するには、検証済みの CLI/モバイル権限昇格、または MCP の allow_all ケイパビリティが必要です。平文を返す前に、配信の意図が監査され、コミットされます。MCP ケイパビリティは端末の権限昇格を引き継ぎません。モバイルで型付きフィールドを開示するには、任意のクイックロック解除が無効でも、システムの生体認証/PIN チェックの成功が追加で必要です。チェックがキャンセルされた場合や利用できない場合、機密値を取得しません。デスクトップのブラウザーエディターには、意図的に秘密開示やパスワードのエンドポイントがありません。機密値には検証済みのネイティブアプリまたは CLI を使用してください。

再利用可能なテンプレート

テンプレートは、type_template: {id, name, fields} を持つ、非公開かつ暗号化・署名されたカードリビジョンです。署名されていない別のデータベースではなく、既存のリビジョン履歴、保管庫認可、競合処理、暗号化されたデバイス/クラウド同期を使用します。通常のカード一覧や検索からは除外されます。組み込みタイプは変更も削除もできません。既存のカードからカスタムテンプレートを作成でき、機密の既定値は常にマスクされます。非 null の機密既定値を指定してテンプレートを直接作成すると拒否されます。

テンプレートの更新や削除で既存カードが書き換わることはありません。カードは独自のフィールドを保持し、テンプレートが削除された後も編集できます。

CLI

クライアントと同じ専用ホームを使用してデーモンを起動してください。

memories daemon
memories type list VAULT
memories type create VAULT Project --from-card CARD
memories type show VAULT TYPE
memories type update VAULT TYPE Project --fields template-fields.json
memories type delete VAULT TYPE
memories card create VAULT --title Ada --type contact
memories card put VAULT --title Notes --type note --input notes.md
memories card field add VAULT CARD Team --id team --kind text --value Core
memories card field add VAULT CARD Status --kind single_select --option Open --option Done
memories card field set VAULT CARD team Platform
memories card field rename VAULT CARD team "Working team"
memories card field mv VAULT CARD team 0
memories card field rm VAULT CARD team
memories card field list VAULT CARD
memories sudo
memories card field add VAULT CARD Key --kind sensitive
memories card field list VAULT CARD --reveal

機密値は非表示の端末プロンプトで入力し、コマンドラインの値として渡すことはありません。数値、チェックボックス、複数選択値には JSON 構文を使用します。カスタムタイプ ID を含め、CLI の一覧/表示で返される短い ID を使用してください。--fields は JSON フィールド配列を受け付けます。

デーモン、FFI、MCP

共有 JSON/C ABI は type_list、type_show、type_create、type_update、type_delete、card_create、card_fields、card_field をサポートします。card_field.operation は action: add|remove|reorder|rename|set を使用し、それぞれフィールド、ID、0 始まりのインデックス、新しい名前または値を指定します。ネイティブフォームの保存では replace も使用し、既存のマスクされた機密値を保持しながら、順序付きフィールド配列をアトミックに保存します。これらの操作は署名付きリビジョンを追加し、元のアセット種類を維持します。

MCP ツールはテンプレートに同じ名前を使い、マスクされた内容の確認には card_fields、変更には card_field_add|remove|reorder|rename|set を使います。card_field_reveal には、単一の field ID、intent: "reveal_plaintext"、短い reason、allow_all スコープが必要です。MCP はカード全体の秘密配信を要求できません。通常の書き込みには write スコープ、タイプ削除には delete スコープが必要です。機密情報の変更には、独立して検証された allow_all MCP ケイパビリティが必要です。これは端末の権限昇格セッションを作成せず、非公開の通常カードも公開しません。

Flutter は既存の memories_call JSON ABI を使用するため、ABI シンボルの変更は不要です。汎用エディターには、タイプ選択、種類別の入力、フィールド名の変更/削除、ドラッグによる並べ替えが含まれます。ホスト型エントリーでも同じフォームを使用し、サーバーが読み取り可能であるという警告を維持します。

ホスト型カードとデバイス封印カード

ホスト型 SaaS RPC は、ベアラーの保管庫とスコープ内でこれらの操作を公開します。サーバーが読み取り可能なホスト型カードも、保存時には保管庫暗号化を使用します。e2e カードには非 null の機密フィールドや内部 field_body を含められません。生の put とフィールド変更のどちらも、平文の機密値を拒否します。機密値を Center に送らずに平文の記述子を編集できます。

ペアリング済みデバイスのモバイル封印フォームは、暗号化エンベロープだけを送信します。汎用カードでは、クライアント上で作成される次のエンベロープ平文を使用します。

{"memories.card":1,"meta":{"card_type":"contact","fields":[
  {"id":"key","name":"Key","kind":"sensitive","value":null}
]},"body":{"text":"notes","sensitive":{"key":"value"}}}

Center が受け取るのはエンベロープであり、この平文ではありません。memories device sealed-get --vault V --card C --field key --reveal は、信頼されたペアリング済みデバイス上で 1 つのフィールドを読み取ります。従来の生の秘密と構造化認証情報のエンベロープも引き続きサポートされます。

互換性

タイプとフィールドのメンバーが欠けている場合、既定値でデシリアライズされます。既存の型なしカードは本文を書き換えずに note として扱います。従来の認証情報は credential として扱い、読み取り時に平文メタデータは通常フィールドに、秘密本文の値は機密フィールドに対応付けられます。認証情報フィールドの編集では既存の構造化認証情報本文が維持されるため、コピー、OTP、注入の利用側は引き続き動作します。バイナリの従来認証情報は、バイトを破棄するのではなく、汎用テキストフィールドへの移行を拒否します。過去の署名付きリビジョンは履歴に残ります。

新しいスキーマを交換する前に、すべてのデバイスをアップグレードしてください。未知の JSON メンバーを拒否する古い実行ファイルは、新しい型付きカードリビジョンを理解できません。