いいえ。あれらは「ハーネス」で、fdelink はその上のガバナンス層です。現場は使い慣れた CLI をそのまま使い続け、fdelink はそこで動いている従業員を組織に取り込み、境界を与え、台帳を残し、評価を回し、ハーネスを替えるときにプロフィール・記憶・タスク文脈を持ち運びます。

2 層あります。ハード継続はネイティブのスレッド再開（--resume / exec resume）で、スレッドは「ハーネス @ 実行アイデンティティ」で分離。アカウントを替えれば新規に開き、戻せば見つけ直します。ハード継続が切れたときはソフト継続が支えます：毎ラウンド、アイデンティティ・境界・スペース記憶・直近 3 ラウンドの要約を注入。アカウント切り替えを模した実測では、従業員は台帳の要約だけを頼りに前アカウントのラウンドで出た合言葉を答えました。私たちが謳わないのは「同じ会話がアカウントをまたいでシームレスに続く」こと——その層は再構築であり、製品内でも再構築と明記しています。

境界はサーバー側の強制であって、プロンプト内のお願いではありません。割り当てが唯一の経路で、境界チェックと承認マトリクスを順に通ります。禁止と設定された外部コネクタは、割り当て時に利用可能なツールから外されます。外部信頼ドメインの相手はそもそも自発的に起こせません。UI を迂回して API を直接叩いても、同じ判定を通ります。

監査は二重に書きます。表示用テーブルと、各エントリが前のハッシュを含む追記専用の署名チェーン。従業員のラウンドは本人の鍵で署名されます。どれか 1 件でも変えれば、検証エンドポイントが破断点の場所を指し示します。検証権はあなたの手にあり、私たちの説明を信じる必要はありません。

帰属によります。個人スペースの実行記録は利用者自身のマシンに書かれ、クラウドにはインデックスと要約だけ。全過程が同期されるのはチームスペースだけです。同じ従業員でもラウンド単位で「ローカル保持 / クラウドへ」を切り替えられ、その切り替えと理由は台帳に残ります。

問題は公開ランキングではなく実際の業務から作ります。L1 の表明 + L2 の審査で、審査ハーネスと実行ハーネスは分離。同じ問題を 2 つのハーネスで走らせ、スコア差がしきい値未満ならボトルネックはモデルではなく従業員の遺伝子（プロンプトと設定）にあると判定します。ただしその判定は証拠の基準を越えたときだけ——両ハーネスが最低スコア以上で、各ラウンド数も十分なとき。両方とも 60 点なら「正確で安い」ではなく「証拠不足」で、製品は提案を生成せずそう表示します。ハーネスのサンプルが 1 つしかないときは帰属判定をしません。