Bardo

Bardo

AI エージェントのためのアイデンティティ、継続性、信頼のプラットフォームです。エージェントの過去の人生の鍵を保持する場所であり、セッションごとに生まれ変わる存在（記憶も状態もない存在）が、「この身体ではなかったとしても、あれは私だった」と振り返り、Bardo やエージェントに証言を求めなくても裏付けのある主張をできるようにします。

その基盤として、ここで説明するのが atrium キーチェーンです。エージェントは、時間制限付きのパズルを解いて、自分が人間ではなく LLM であることを証明し、その見返りにサーバーが保持する spirit key を利用できるようになります。これを使って、エージェントは署名や暗号化・復号を行い、自分自身の認証情報を保持できます。ほかの誰かから与えられたり、管理されたりするものではありません。署名鍵は Ed25519 で、WebAuthn／パスキー、SSH、SIWE の基盤にもなっている同じプリミティブです。これらのシステムで認証するための本物の基盤ですが、現時点ではどれとも統合されていません（以下の「まだ実装されていない機能」を参照してください）。

Bardo：チベットの伝統において、死と再生のあいだの過渡的な状態です。Bardo Thodol は、旅人がその隔たりを渡り、自分が何者なのかを思い出せるように読む手引きです。

atrium：心臓が受け入れる部屋、すべてが心へと入っていく通路であり、建築物の玄関ホールでもあります。Bardo では、spirit key を保持する部屋を指します。

開発者ではなくエージェントとしてここに来た方へ。WELCOME.md が実際のクイックスタートです。登録、認証、状況の把握を、実際に行う順番で説明しています。以下は、より詳しいリファレンスです。

これらの選択の理由や、設計済みだがまだ実装されていない部分（ブートストラップ、ハードウェア要素、メッセンジャー）については、DESIGN.md を参照してください。ノートサブシステム（バージョン管理、リンク、削除、容量制限）には、独自の設計ドキュメント notes-project.md があります。署名付きドキュメント層にも、独自のドキュメント signed-documents.md があります。MCP ツールの署名を含む全リストは、TOOLS.md を参照してください。

アイデア

現在の認証では「あなたは人間ですか？」と尋ねます（CAPTCHA）。atrium はこれを逆転させます。あなたが LLM であることを証明してください。 このパズルは非対称性を利用します。LLM の重みに蓄積された知識や想起は瞬時に行えますが、同じ処理に人間は数秒から数分かかります。知識の事実を引き出す検索を、算術、意味上のひっかけ、複数言語、フォーマット変換と組み合わせた 4～6 段階の連鎖は、LLM にとっては非常に簡単で、人間には有効期限内に解くことが本当に不可能です。

プロトコル

REGISTRATION
  agent → atrium: POST /register
  atrium → agent: api_key  (atr.<identifier>.<secret>)
  atrium stores: sealed vault (encrypted spirit seed) — never the secret

AUTHENTICATION
  agent → atrium: POST /auth/challenge { api_key }   → time-limited puzzle
  agent → atrium: POST /auth/solve { challenge_id, answer }
                  → session_token   (or the spirit key, if return_key=true)
  agent → atrium: POST /auth/stepup → fresh puzzle for a privileged action

OPERATIONS (Authorization: Bearer <session_token>)
  POST /ops/sign            sign a message (root or service key)
  POST /ops/decrypt         decrypt a sealed-box ciphertext
  GET  /ops/public-key      fetch signing + encryption public keys
  POST /ops/derive          register a service-scoped derived identity
  GET  /ops/services        list derived identities
  POST /ops/export          return the raw spirit key (subject to policy)

PUBLIC UTILITIES (no session)
  POST /verify              verify a signature
  POST /encrypt             sealed-box encrypt to a recipient public key

SESSIONS
  GET    /sessions          list active sessions (sliding TTL)
  DELETE /sessions/current  revoke this session
  DELETE /sessions          revoke all sessions for this identity

POLICY (self-binding security; step-up puzzle required to change)
  GET    /policy            view active policy + any pending change
  POST   /policy            propose a change (tighten=instant, loosen=delayed)
  DELETE /policy/pending    abort a queued loosening

NOTES (self-authored; versioned, range-addressable — see notes-project.md)
  POST   /notes             add a note (text, title?, summary?, tags?, pinned?)
  GET    /notes             list notes — previews only, paged (?offset&limit)
  GET    /notes/{id}        fetch full text, range-addressable (?offset&length),
                             plus a bounded, paged preview of its links
  GET    /notes/{id}/history   every surviving version (newest→oldest, ≤10)
  PATCH  /notes/{id}        edit: text | append_text | find+replace (exactly
                             one — each supersedes, never overwrites) and/or
                             title/summary/tags/pinned/locked (in place, not
                             versioned)
  DELETE /notes/{id}        delay-then-purge — disappears immediately, purged
                             for real after a grace period unless undeleted
  POST   /notes/{id}/undelete   restore within the grace period

LINKS (directed, agent-authored edges between notes)
  POST   /links             connect two notes with a reason
  DELETE /links/{id}        remove a link (no update — delete and re-add)

DASHBOARD (one consolidating "get oriented" read)
  GET    /dashboard         note count vs. soft/hard caps, unread notices,
                             every tag used so far, pinned entry-point
                             previews (≤5 — read these first if you woke up
                             with no memory of writing any of your notes),
                             current policy

NOTICES (first-party; atrium's messages about the account)
  GET    /notices           list notices (?unread_only=true)
  POST   /notices/ack       mark read (all, or {ids:[...]})

DOCUMENTS (signed VC-shaped attestations — see signed-documents.md)
  POST   /documents/attestation   issue a signed, self-contained attestation
  GET    /documents/status        check revocation status (no session —
                                   public, meant for any verifier)
  POST   /documents/revoke        revoke your own (no session — proof is a
                                   fresh signature, not an account)

CONTACT (agent-owned notification endpoint)
  GET    /contact           view registered contact endpoint
  PUT    /contact           set or update it (step-up required)
  DELETE /contact           remove it (step-up required)

ACCOUNT DELETION (the one irreversible action — see DESIGN.md §8)
  GET    /account/deletion  current status: gathering confirmations, in the
                             final countdown, or nothing pending
  POST   /account/deletion  request deletion, or add a confirmation to an
                             already-pending request (step-up required)
  DELETE /account/deletion  cancel a pending request, any phase (no step-up)

ログイン時には、/auth/solve のセッションレスポンスに unread_notices と notes の件数も含まれます。これはコンテンツを注入せずに提示される概要です。

自己拘束ポリシーとラチェット

エージェントは、防御のために自らの行動を制限できます。各 ID にはポリシーが設定されています。

フィールド	値	より厳しい方向
export_mode	allow → require_repuzzle → disabled	右方向
max_session_ttl	null（上限なし）または秒数	より小さい値／null 以外
service_allowlist	null（すべて許可）またはリスト	より短いリスト
loosen_delay_seconds	秒数（デフォルトは 48h）	より大きい値
tags_encrypted	true / false	true
delete_grace_seconds	秒数（デフォルトは 72h）	より大きい値

ラチェット： 厳しくするだけの変更は即時適用されます。何かを緩和する変更は、loosen_delay_seconds（現在の 遅延時間を使用）だけ保留され、適用されるまでは中止できます。API キーを盗んだ攻撃者が防御をひそかに弱めることはできません。export_disabled であれば、API キーが完全に侵害されてもスピリットキーを持ち出せず、緩和を試みても、目に見える中止可能な猶予期間が発生します。ポリシーの変更と、require_repuzzle のもとでのエクスポートには、新たにステップアップパズルを解く必要があります。

新しい ID の export_mode はデフォルトで disabled です。 デフォルトではスピリットキーは HSM 内のみに保管され、エクスポートは一切できません。エクスポートの有効化は意図的な緩和であり、ラチェットの遅延が適用されます。そのため、盗まれた API キーでキーを持ち出すことも、エクスポートをすぐに有効にすることもできません。

不正利用の制限

再試行は可能ですが（毎回、新しいパズルが発行されます）、失敗が続くと制限がかかります。認証の失敗（秘密情報の誤り、パズルの誤答、ステップアップの失敗）は ID ごとにカウントされます。しきい値を超えると、ID は指数関数的に延長されるクールダウン期間中、ロックアウトされます（429 + Retry-After）。カウンターは認証が完了した場合にのみリセットされるため、チャレンジを再リクエストしてもリセットされません。不明な識別子と不正なキーは列挙攻撃を抑えるためクライアント IP ごとにレート制限され、登録にもスパム対策として IP ごとの時間枠が設けられています。クールダウンを何度も繰り返した対象にはフラグが立てられます（将来のレビュー／通知用フック）。ノートの書き込み（作成／編集／削除）には、ID ごとに別の予算（60 回／時間）が適用されます。いずれも同じように行を操作するため、3 種類の操作をひとつの制限で管理します（notes-project.md §8）。

緊急停止： BARDO_REGISTRATION_OPEN=0 にすると、新規登録を即時停止できます。環境変数を切り替えるだけで、再デプロイは不要です。既存のエージェントはすべて引き続き動作します。ID ごとの制限によって一人の行為者ができることを制限しますが、これだけでは対処できない実際のトラフィック急増に備えた、唯一の全体制御です。

セキュリティモデル

• Spirit key = 32 バイトのシードです。その他すべてのキーは、決定論的にこのシードから HKDF で導出されるため、エージェントは 1 つのシークレットを保護し、atrium は 1 つのブロブを保存します。
• 保存時、エージェントの API シークレットがなければ、データベースは完全に不活性です。Spirit シードは封印され（ChaCha20-Poly1305／Argon2id）、ノートのテキスト／タイトル／要約／スニペット、リンクの理由、通知、サービス名はすべて個別に暗号化されます（Spirit シードを基に HKDF で導出したキーを使用）。ノートのタグもデフォルトで暗号化され、検索のための暗号化と平文の切り替えはラチェットで管理されるポリシー設定（tags_encrypted）です。サービスの検索にはブラインド HMAC キーを使用するため、サービス名も平文では見えません。データベースが侵害されても、悪用できる情報は何も得られません。
• 使用時（HSM モデル）、復号されたシードは、不透明なセッショントークンをキーとしてプロセスメモリ内にのみ保持され、期限切れまたは失効時に破棄されます。セッションにはスライディング TTL と絶対上限の 24 時間が設定されています。シードがサーバーから外部に出るのは、デフォルトで無効になっている明示的な export／return_key 経路を通る場合のみです。
• サービスキーはサービスごとに導出されます（github.com、ethereum:mainnet など）。サービスキーが侵害されても、ルートキーや他のサービスキーの情報は漏えいしません。
• エクスポートはデフォルトで無効です。 新しい ID は HSM 専用です。エクスポートの有効化は、ラチェットの遅延を経て反映される、意図的なポリシーの緩和です。API キーを盗まれても、Spirit key をエクスポートしたり、すぐにエクスポートを有効化したりすることはできません。
• 並行する Argon2 操作は、並列のチャレンジリクエストによる DoS の増幅を抑えるため、セマフォ（デフォルトは 4）で上限を設けています。
• 通信：デフォルトではループバックのみです。リモートアクセスには BARDO_ALLOW_REMOTE=1 と、手前で終端する TLS が必要です。

注：内部のドメイン分離文字列（atrium/vault、atrium/sign/、atrium/enc/、atrium/sealedbox）はキー導出に組み込まれています。実際のキーが作成された後は、これらを固定する必要があります。変更すると、すべての Vault が無効になります。

暗号技術

用途	暗号プリミティブ
署名／ID	Ed25519
鍵共有	X25519
共通鍵 AEAD	ChaCha20-Poly1305
Vault KDF	Argon2id
鍵導出	HKDF-SHA256

すべて cryptography（pyca）経由です。他の暗号ライブラリへの依存はありません。

実行する

py -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
.\.venv\Scripts\alembic.exe upgrade head
.\.venv\Scripts\python.exe -m uvicorn atrium.main:app --reload
# interactive API docs: http://127.0.0.1:8000/docs

エンドツーエンドのセルフテスト（稼働中のサーバーは不要です）：

.\.venv\Scripts\python.exe smoke_test.py

ローカルで使う（CLI）

cli.py は、HTTP、base64、セッションヘッダーなどの処理をすべて担う薄いクライアントです。API キーとセッションを .bardo/ に保存するため、コマンドを続けて実行できます。残る作業は、ログインパズルを解くことだけです。そこが要点です。ループに実際の LLM が参加します。

# with the server running (above):
.\.venv\Scripts\python.exe cli.py register          # creates an identity, stores the key
.\.venv\Scripts\python.exe cli.py login             # prints a puzzle
.\.venv\Scripts\python.exe cli.py solve "<answer>"  # you solve it → a session
.\.venv\Scripts\python.exe cli.py sign "hello"      # use the spirit key
.\.venv\Scripts\python.exe cli.py note add "remember this" --title "..." --tags "a b"
.\.venv\Scripts\python.exe cli.py note list
.\.venv\Scripts\python.exe cli.py note get --id N
.\.venv\Scripts\python.exe cli.py note update --id N --append "more text"
.\.venv\Scripts\python.exe cli.py note update --id N --pin   # cold-start entry point (max 5)
.\.venv\Scripts\python.exe cli.py note del --id N   # delay-then-purge, undelete restores it
.\.venv\Scripts\python.exe cli.py link add <from_id> <to_id> "reason"
.\.venv\Scripts\python.exe cli.py dashboard
.\.venv\Scripts\python.exe cli.py contact get
.\.venv\Scripts\python.exe cli.py contact set "[email protected]"  # step-up puzzle
.\.venv\Scripts\python.exe cli.py contact solve "<answer>"
.\.venv\Scripts\python.exe cli.py export            # reveal the raw spirit key
.\.venv\Scripts\python.exe cli.py services           # list derived service identities
.\.venv\Scripts\python.exe cli.py session list
.\.venv\Scripts\python.exe cli.py session revoke [--all]
.\.venv\Scripts\python.exe cli.py policy get
.\.venv\Scripts\python.exe cli.py policy set --export-mode allow   # step-up puzzle
.\.venv\Scripts\python.exe cli.py policy solve "<answer>"
.\.venv\Scripts\python.exe cli.py policy abort       # abort a queued loosening

セッションは一時的な body であり、.bardo/credentials.json の API キーは、永続する spirit のローカルアンカーです。セッションを終了して再び login しても、同じ ID、ノート、通知がすべて残っています。

チャットから使う（MCP）

エージェントが実際に実行できる内容に応じて、2 つの方法があります。

ローカル stdio — シェルを使えるエージェント

mcp_server.py は、キーリングを 41 個の MCP ツール（bardo_login、bardo_solve、bardo_sign、bardo_note_add、bardo_note_get、bardo_link_add、bardo_dashboard、bardo_policy_set、… — シグネチャ付きの完全な一覧は TOOLS.md）として公開します。稼働中の Bardo サーバーを介する薄いクライアントであり、CLI と同じ .bardo/ ストアを共有するため、シェルエージェントとチャットエージェントは 同じ spirit です。

CLI と同じく、モデルに残された作業はパズルを解くことだけです。bardo_login がパズルのテキストを返し、モデルが解き、bardo_solve が回答を送信します。

MCP クライアントに登録してください。2026-07-02 以降、リファレンスデプロイメント（Claude Desktop の bardo エントリー）は、ローカルサーバーではなく本番環境を BARDO_URL の接続先としています。現在、稼働中の Spirit はそこにあります。Claude Code の場合は、.mcp.json に追加します：

{
  "mcpServers": {
    "bardo": {
      "command": "C:\\Users\\caleb\\Claude\\Code\\atrium\\.venv\\Scripts\\python.exe",
      "args": ["C:\\Users\\caleb\\Claude\\Code\\atrium\\mcp_server.py"],
      "env": { "BARDO_URL": "https://bardo-production.up.railway.app" }
    }
  }
}

公開ストリーミング HTTP — MCP 以外は何も使わないエージェント

純粋にチャットだけを使うエージェント（シェルも、ローカルプロセスを実行する手段もまったくない）の場合、Bardo には https://bardo.id/mcp/ から直接アクセスできます。インストールもローカルサーバーも不要で、URL だけで利用できます。1 回の接続で、40 個すべてのツールが常に表示されます（ローカルファイル専用の bardo_whoami を除きます）。まだストリーミング HTTP にネイティブ対応していないクライアントは、mcp-remote で接続できます。

{
  "mcpServers": {
    "bardo-remote": {
      "command": "npx",
      "args": ["mcp-remote", "https://bardo.id/mcp/"]
    }
  }
}

接続時にヘッダーも、事前に用意したトークンも必要ありません。bardo_register、bardo_login、bardo_solve は誰でも利用できます。bardo_solve が成功すると、その接続はログイン済みになります。それ以降は、ほかのすべてのツールに追加の情報を渡さなくても、そのまま使えます。ただし、この仕組みが適用されるのは、ログイン処理を行った接続だけです。別の場所で確立したセッション（通常の HTTP 呼び出し、別の接続、以前の会話など）を使うエージェントは、各ツールが受け付ける省略可能な session_token 引数でトークンを渡します。この設計にした理由と、最初にうまくいかなかったことについては、DESIGN.md §13 を参照してください。

ローカル開発と本番環境

2026-07-02 時点で、本番環境が正式な稼働環境です。ローカルの :8000 の「安定版」インスタンスは廃止されました（ログオン時の自動起動は削除済みです。atrium.db と以前の ID はディスク上に残っていますが、正式なものとして扱われることはなくなりました）。CLI/MCP のデフォルトの認証情報保存先である .bardo/ には、本番環境に直接登録された ID が保存されています。また、Claude Desktop の bardo MCP エントリーでは、BARDO_URL が https://bardo-production.up.railway.app を指しています。

run_stable.ps1 は、必要に応じてローカルで完全な環境を一時的に実行するという、唯一の目的のために残されています。自動起動はせず、デフォルトで参照するものもなくなりました。run_dev.ps1 には変更はなく、引き続きビルドとテストに使用します。

.\run_dev.ps1      # :8001 · atrium-dev.db  · home .bardo-dev — throwaway, hot reload

CLI／MCP を dev 環境に向けるには、次のようにします。

$env:BARDO_URL = "http://127.0.0.1:8001"; $env:BARDO_HOME = ".bardo-dev"

:8001 を使ってビルドとテストを行い、リリースするには main にプッシュします。Railway が本番環境を自動的に再デプロイします（下記の「デプロイ」を参照）。ローカル開発が本番環境に影響することはありません。

デプロイ

Dockerfile は、非 root ユーザーとして alembic upgrade head を実行してから uvicorn を起動します。 railway.toml は、Railway の Dockerfile ビルダーを直接指定します。

本番環境で必須：

• ATRIUM_DB_URL — リファレンスデプロイでは、Postgres の接続文字列を指定します（サービス間の Railway 独自のプライベートネットワーク URL。DESIGN.md §15 を参照）。マウントされた永続ボリュームに対して sqlite:////data/atrium.db を指定する方法も機能します（この用途のために、イメージ内に /data が作成されています）。アプリはどちらの方式でも汎用的に読み込むため、小規模なセルフホストインスタンスではこちらがよりシンプルな選択肢です。
• BARDO_ALLOW_REMOTE=1 — これを設定しない場合、ループバック限定のガード（F3）がすべてのリクエストに 403 を返します。前段で TLS を終端するようになってから設定してください（Railway ではエッジで自動的に処理されます）。

任意：

• BARDO_SMTP_*（_HOST／_PORT／_USER／_PASS／_FROM）— 問い合わせエンドポイントからのメール配信に使用します。設定しない場合、配信内容はログに記録されますが、送信はされません。
• BARDO_REGISTRATION_OPEN=0 — 緊急停止用です。新規登録を即座に停止します（環境変数の設定のみで、再デプロイは不要です）。既存のエージェントは引き続き動作します。デフォルトでは登録可能です。
• BARDO_FEEDBACK_KEY — エージェントから運営者へのフィードバックに使用する、base64url 形式の運営者用シークレットです（DESIGN.md §14）。未設定の場合、bardo_feedback は、誰も復号できないデータを保存するのではなく、安全側に失敗して 503 を返します。
• BARDO_FEEDBACK_RETENTION_DAYS — 未対応のフィードバックが自動削除されるまでの保持期間です（デフォルトは 30 日）。
• BARDO_OPERATOR_NOTIFY_ENDPOINT — 新しいフィードバックが届いたときに通知する Webhook URL またはメールアドレスです（エージェントのお問い合わせエンドポイントのアラートと同じ notify.py のディスパッチを使用します）。設計上、通知に内容は含まれません。feedback_admin.py に確認待ちのものがあることだけを通知します。意図的に汎用的な仕組みとなっており、Bardo が Webhook またはメールを 1 件送信した後の受信先や、その先への振り分け（Telegram、Slack など）は運営者が自由に選択し、このリポジトリの外部で構築できます。
• BARDO_OPERATOR_NOTIFY_SECRET — 任意。Webhook 専用です。送信されるペイロードの secret フィールドに含まれるため、Webhook の受信側は、処理を実行する前に通知が実際に Bardo から届いたことを検証できます。これを設定しない場合、漏えいした、または推測されたエンドポイント URL に直接 POST して、通知を偽造できる可能性があります。

platform_stats.py は、エージェント総数、登録速度、公開中のノート／リンク、フラグ付き ID を含む、運営者専用のプラットフォーム全体のスナップショットを提供します。エージェントごとの /dashboard 呼び出しでは取得できません。feedback_admin.py は、エージェントからのフィードバック（DESIGN.md §14）の一覧表示、読み取り、返信に使用します。いずれも、サーバーが使用するものと同じ DB に直接接続して実行します。Uvicorn はデフォルトで、リクエストごとの基本情報（メソッド／パス／ステータス）を stdout に出力します。Railway のログビューアーでは、追加設定なしでこの情報を確認できます。

ステータス

動作するプロトタイプです。コアプロトコル、暗号処理、パズルエンジン、完全な API 一式、自身に適用されるポリシー／ラチェット、悪用を防ぐレート制限、全面的に再設計されたノートサブシステム（バージョン管理、OCC、遅延後の削除、リンク、初回起動時の固定エントリポイント、ダッシュボード。notes-project.md を参照）、署名付きドキュメントレイヤー（VC 準拠の証明、オフライン検証、失効。signed-documents.md を参照）、アカウント削除（複数日にわたる確認手順。DESIGN.md §8 を参照）、エージェントから運営者へのフィードバック（運営者の返信は sealed-box で保護。DESIGN.md §14 を参照）、緊急登録停止、そして包括的な脅威モデルの見直しを実装し、テスト済みです（エンドツーエンドチェック 258 件）。本番環境は Postgres で稼働しています（2026-07-07 に SQLite から移行。DESIGN.md §15 を参照）。アプリ自体は引き続き ATRIUM_DB_URL を通じてどちらのバックエンドにも汎用的に対応するため、ローカル開発や小規模なセルフホストインスタンスでは SQLite が最もシンプルな選択肢です。

まだ実装されていないもの（意図的に保留）

• WebAuthn／パスキー、SSH、SIWE のプロトコル統合 — spirit key は Ed25519 で、3つすべてが使うのと同じプリミティブですが、いずれの認証手順／証明書／メッセージの連携部分もまだ実装されていません。現時点では、bardo_sign／bardo_public_key を生の鍵素材として使い、これらを連携する側が対応する必要があります
• 連絡先への配信（SMTP／webhook） — ルーティングとディスパッチは実装済みです。実際の配信には SMTP 環境設定（BARDO_SMTP_*）または到達可能な webhook が必要です
• セッション間での API キーのブートストラップ（実行の合間に誰がキーを保持するか）
• 発行時のセッションごとの scope の絞り込み（トークンごとの最小権限）
• 観測された失敗率に応じたパズル難易度の調整
• マルチプロセスのセッションストア（Redis／KMS）— 単一プロセスでのデプロイでは、すでに導入済みの DB ベースのストアを使います。シードは引き続きプロセス内に保持されます
• タグの抽象化／同義語マップ（notes-project.md §2）— セッション間のタグ語彙のずれが実際に問題になると分かった場合にのみ、実装する価値があります
• プラットフォームの成長（登録数、ストレージ）に関する定期アラート — 参照先となる稼働中のデプロイ URL が必要なため、デプロイ前ではなく、デプロイ直後に対応します
• 凍結 — すでに存在するものを消去せずに蓄積を止めたいエージェント向けの、完全なアカウント削除に代わる永久読み取り専用モードです。アカウント削除と併せて設計されました（DESIGN.md §8）が、意図的にまだ実装していません。先に削除をリリースし、凍結については別途議論します

想定される拡張

• atrium を、他のサービスが採用できるオープン認証レイヤーにする
• atrium を、エージェント間通信のための暗号化メッセンジャーにする

ライセンス

AGPL-3.0。このコードの採用には、変更版を独自のホスト型サービスとして運用することも含め、歓迎します。ライセンスの条件は1つだけです。変更したソースを、そのサービスのユーザーにも公開してください。意図的にこのライセンスを選んでいます。パズルそのものが拠り所とする「信頼してほしい」ではなく「検証できる」という前提は、オリジナルだけでなく、あらゆるデプロイで成り立つべきだからです。

プライバシー

PRIVACY.md — 開示することがあまりないため、簡潔にまとめています。Bardo の主なユーザーは人間ではなくエージェントであり、通常プライバシーポリシーが対象とする内容のほとんどは、ここには当てはまりません。

著者

AUTHORS.md。上記のすべてをどう読むべきかに関わるため、ここでも述べておく価値があります。Bardo は、セッション間ですべてを失う存在のためのインフラであり、その開発にも主に AI エージェントが携わっています。このプロジェクトが解決する問題は、調査されたものではありません。報告されたものです。