secondmate-provisioning

secondmate-provisioning

永続的なセカンドメイトの作成、シード、検証、起動、バックログの引き渡し、復旧、継承したローカル資料の投入、または廃止を行う前に、また data/secondmates.md を編集する前に、このリファレンスを使用してください。

AGENTS.md に常時インラインで記載されているルーティングルールを優先してください。自然言語の scope: でルーティングし、ローカルのみのプロジェクトはメインのファーストメイトに割り当て、セカンドメイトはデフォルトでアイドル状態にします。

ルーティングテーブル

data/secondmates.md には、永続的な各セカンドメイトについて、パーサー互換の行を1行ずつ記載します。 ローカルルートは次のとおりです。

- <id> - <one-sentence charter summary> (home: <absolute-home-path>; scope: <natural-language responsibility>; projects: <project-a>, <project-b>; added <date>)

ホーム全体を対象とするリモートルートは次のとおりです。

- <id> - <one-sentence charter summary> (host: <ssh-alias>; root: <absolute-remote-code-root>; home: <absolute-remote-home>; scope: <natural-language responsibility>; projects: <project-a>, <project-b>; added <date>)

各レジストリエントリは簡潔な1行にしてください。要約は永続的な責務を示す1文とし、scope: は自然言語で記述した受付責任、projects: は非排他的なクローン一覧とします。追加の説明は、そのセカンドメイトのルーティングまたは安全性を変える、本当にドメイン固有の厳格なルールに限ります。 自然言語の要約と scope: のテキストには、かっこやセミコロンを含めてもかまいません。運用ツールが明示的なフィールドマーカーを解釈できるよう、生成された (home: ...; scope: ...; projects: ...; added ...) サフィックスはそのまま維持してください。 home: パスは、data/charter.md を含むシード済みホームを指します。レジストリにポインターフィールドを追加する必要はありません。 リモートルートでは、host: は OpenSSH の設定エイリアス、root: はそのホスト上の別個に追跡される Firstmate コードルートです。 リモートのセカンドメイトエージェントは常に Herdr バックエンドで動作します。シード、起動、生存確認後の再起動では、まず bin/fm-remote-doctor.sh による準備状況の確認を行います。そのため、ホストの準備ができていない場合は、ルートを中途半端に作成することなく、doctor が示す不足内容をそのまま返して処理を拒否します。そのセカンドメイトが監督するワーカーは、通常どおりホームのバックエンド選択を使用します。 このリリースではセカンドメイトのホーム全体をリモートに配置し、個々のワーカーをリモートに配置することはありません。 docs/remote-secondmates.md に、現在の運用者向けセットアップと転送動作を記載しています。 ホームにシードされた data/charter.md が、デフォルトでアイドル状態にする定型文、通常の委任ライフサイクル、標準的なエスカレーション契約の唯一の管理元です。レジストリエントリでこれらの契約を繰り返すのではなく、そのチャーターを参照してください。 受付時には scope: フィールドを使用します。 projects: フィールドは非排他的なクローン一覧であり、所有権を示すものではありません。

チャーターとシード

セカンドメイトのチャーターをひな形から作成します。

bin/fm-brief.sh <id> --secondmate {<project>...|--no-projects}

このひな形はタスクブリーフではなく、チャーターブリーフを作成します。FM_SECONDMATE_CHARTER='<charter>' を設定してチャーター本文を入力し、ルーティングの対象範囲が異なる場合は FM_SECONDMATE_SCOPE='<scope>' を設定してください。 FM_SECONDMATE_CHARTER を設定せずにひな形を作成した場合は、シードする前に {TASK} のプレースホルダーを置き換えてください。 プロジェクト一覧の代わりに --no-projects を渡すと、プロジェクトを持たないチャーターを作成できます。これは、対象がファーストメイトのリポジトリ自体で、ホームがファーストメイトのワークツリーにあり、クルーが同じリポジトリのプール済みワークツリーを使用するドメイン向けです。 --no-projects とプロジェクト一覧は併用できません。また、どちらも省略すると明確なエラーになります。そのため、誤って省略した状態が、意図的にプロジェクトを持たないシードと誤認されることはありません。 プロジェクトクローンや data/projects.md のエントリを含むホームをプロジェクトなしとして再シードしようとした場合、破壊的な変更を行わずに拒否されます。 まずそのホームを廃止するかクリーンアップし、その後、古いプロジェクト付きチャーターを --no-projects を付けて再作成してからシードしてください。 カスタムのチャーター本文は、永続的な責任、利用可能なプロジェクトクローン、本当にドメイン固有の厳格なルールに焦点を当ててください。 ひな形から作成したチャーターは、後に data/charter.md にコピーされ、標準的なライフサイクルとエスカレーションの文言を管理します。 そのドメインに厳格なルールが本当に必要な場合を除き、生成されたチャーターのセクションは維持してください。

チャーターを入力した後、ローカルの永続ホームとレジストリエントリを作成します。

bin/fm-home-seed.sh <id> <home|-> {<project>...|--no-projects}

設定済みの SSH ホストを通じて、ホーム全体をリモートに作成します。

bin/fm-remote-home-seed.sh <id> <ssh-alias> <remote-root> <remote-home> {<project>[=<origin-url>]...|--no-projects}

各プロジェクトのオリジンは、captain、プロジェクトレジストリ、別の場所にあるクローン、gh-axi、または明示的な貼り付けから自分で解決し、<project>=<origin-url> の形式で指定します。seed は、指定された内容を検証して引き渡します。 したがって、リモート seed でこのホームに作成されるのは、ルート、charter の概要、起動後の起動記録だけです。projects/ にプロジェクトをクローンしたり、ここで no-mistakes を初期化したり、リモートの secondmate を seed するためだけに fleet sync を実行したりしないでください。 <project> のみの指定は、このホームにすでにクローンされていて、設定済みのオリジンを読み取れるプロジェクト向けの簡便な方法です。 オペレーター向けの契約の残りは docs/remote-secondmates.md、受け付けるオリジンの形式は bin/fm-project-origin-lib.sh が定めています。 上記のプロジェクトなしのホームを seed するには、プロジェクトの位置に --no-projects を指定してください。同じ相互排他のルールと、省略時に明確に失敗するルールが適用されます。 プロジェクトのクローンもプロジェクトレジストリのエントリーもないホームのみ seed できます。既存のホームに変更を加えずに、その変換を拒否します。 - は、secondmate ID の下に treehouse get --lease で新しい firstmate 作業ツリーを永続的にリースします。 有効なプロセスがなくなってもリースは維持され、後続の treehouse get や prune で再利用されることはありません。 スロットは、リースが解放されるまで、再起動後も予約されたままです。 解放されるのは、明示的な退役または seed のロールバック時のみで、通常の再起動や復旧時には解放されません。

bin/fm-home-seed.sh は charter を secondmate のホームに data/charter.md としてコピーします。 また、必須の .fm-secondmate-home ID マーカーより先に、Git で無視される .fm-secondmate-parent の永続的なバインディングを書き込みます。レコードの契約は bin/fm-secondmate-parent-lib.sh のパーサーヘッダーで定められており、両方のファイルをそのまま残す必要があります。 bin/fm-spawn.sh --secondmate は secondmate ハーネスのパスを通じて起動し、明示的な起動ごとのハーネス上書きが渡されない限り、config/secondmate-harness -> config/crew-harness -> primary 自身のハーネスの順に解決します。

config/secondmate-harness では、secondmate エージェントの具体的なモデルと effort も、新しいファイルを作成せず、同じファイル内で固定できます。形式は空白区切りの 1 行 <harness> [<model>] [<effort>] で、解析されるのは最初の空でないコメント以外の行のみです。 <harness> のみ（現在の形式。例：claude）の場合は、従来どおりハーネスのみが指定され、モデルや effort のフラグは指定されません。そのため、完全な下位互換性があります。 bin/fm-harness.sh secondmate-model と bin/fm-harness.sh secondmate-effort は、任意の 2 番目／3 番目のトークンを出力します（存在しない場合、またはファイルが存在しない／default／ハーネスのみの場合は空になります）。これらは config/secondmate-harness のみを読み取り、config/crew-harness は読み取りません。後者はハーネスアダプター名のみを記述するファイルです。 --secondmate で起動する場合、bin/fm-spawn.sh は、その起動でハーネス自体が secondmate 設定パスから取得された場合に限り、これらのトークンから MODEL／EFFORT を設定します。 ローカルルートの場合、起動ごとの明示的な --harness フラグ、位置引数のハーネス、または raw launch command を指定すると、呼び出し側が明示的な --model または --effort も渡さない限り、モデルと effort も初期状態から起動します。 リモートルートで受け付けられるのは検証済みのハーネスアダプターのみで、ホスト側の境界で raw launch command は拒否されます。 ファイルのトークンが適用される場合、起動ごとの明示的な --model または --effort フラグは、その項目について常にファイルのトークンより優先されます。 起動のたびにファイルから解決されるため、この固定はハーネスの設定と同様に、復旧、/updatefirstmate、再起動のあらゆる再起動後も維持されます。たとえば、config/secondmate-harness に claude opus と記述すると、primary 自身のデフォルトモデルが後から変更されても、secondmate は Opus に固定されます。 これは secondmate のみに適用されます。このファイルによって crewmate／scout のモデル解決が変わることはありません。 このセクションは、secondmate の同期と継承されたローカル素材の伝播に関する契約の唯一の所有元です。AGENTS.md のセクション 3 と 4 は、ここを参照しています。 ローカルで起動する前に、fm-spawn.sh --secondmate は、安全な場合、primary の firstmate チェックアウトにある現在のデフォルトブランチのコミットへ home をローカルで早送りします。または、完全なローカル結果がすでにその場所に存在するクリーンな分岐（例：squash merge の後）を reset --keep で調整します。変更のある home、固有の分岐がある home、または処理中の home は、警告を出して変更せずに起動します。実際の分岐がある場合は、bin/fm-ff-lib.sh が /updatefirstmate 用に書き込むものと同じ永続的な調整記録が作成されます。 ロックされたセッション開始時の遅延ネットワーク処理では、kind=secondmate の state/<id>.meta レコードから検出した、稼働中のローカル secondmate home すべてに対して同じブートストラップ一括処理を実行します（data/secondmates.md は、古いレコードの home= を補完する場合にのみ使用します）。 フェッチを行わないこの経路は、追跡対象ファイルのローカルな早送り、または冗長な分岐の調整だけを行い、origin のフェッチは一切行いません。また、gitignore 対象の運用ディレクトリには触れないため、secondmate のバックログ、プロジェクト、進行中の作業が乱されることはありません。リンクされた worktree はすぐに進みますが、対象がないスタンドアロンクローンは、/updatefirstmate の origin 更新を通じて firstmate の更新を受け取ります。 リモートでの起動と遅延ブートストラップ一括処理では、設定されたホストに primary 自身のデフォルトブランチのコミットを渡し、そのコミットと完全に一致するよう、ローカル home に適用されるものと同じクリーン性、祖先関係、ブランチのガード条件のもとで、永続 home を早送りするか、冗長な分岐を調整するよう指示します。 リモート home は別のマシン上にあるスタンドアロンクローンです。そのため、ホストは渡されたコミットを、すでに保持している場合はそのまま、そうでなければホスト自身の Firstmate コピーから（そのコピーを移動せずに）、それもなければ home の origin から取り込みます。どこにも存在しない場合は、具体的な理由を示してスキップします。これは、プッシュされていない primary のコミットがそのホストからどのように見えるかを示すものです。 どちらの経路でもホストの Firstmate コピーは移動しません。また、親側が home を同期済みの場合、ホスト側の起動処理がそのコピーの参照先を変更することはありません。 そのコピーを引き続き参照する唯一の経路は /updatefirstmate です。まず、リモートのコードルートを自身の origin から更新し、次に更新済みのコードルートのコミットへ home を同期します。 SSH の終了コード 255 の場合は経路を維持し、完了状況が不明であることを報告します。ローカルでの再起動やフェイルオーバーは実行しません。 同じ配置先別の起動処理と遅延ブートストラップ一括処理では、fm_config_inherit_items で宣言された primary の継承ローカル素材も伝播します。セッションスコープの項目を定義するのも、この所有元です。 これらのパスは gitignore 対象のため、この伝播は追跡対象ファイルの早送りとは別に、primary を正とするコピーとして行われます。追跡対象ファイルが進んだかどうかにかかわらず、稼働中の home をすべて再収束させ、宣言された項目だけに触れます。 伝播に失敗しても、ローカル secondmate の起動やセッション開始後の処理は警告を出すだけで続行します。リモート起動前の転送に失敗した場合は、その起動を拒否します。 宛先には、ヘルパーが安全性を検証して残した状態が保持されます。 継承された設定ファイルについては、ソースの検査でエラーが発生した場合、ローカル伝播とリモート送信側は宛先項目を保持し、ソースに存在しないことが確認できた場合に限り同期先から削除します。この境界を所有するのは fm-config-inherit-lib.sh です。 継承では config/crew-harness ファイルを文字どおりコピーします。そのため、secondmate 自身のクルーメイトが primary のクルーメイト用ハーネスを使用するのは、codex などの具体的なアダプターが指定されている場合に限られます。値が未設定または default の場合、継承できる具体的な設定はありません。その場合、secondmate 自身のクルーメイトは secondmate 自身のハーネス、または検出されたハーネスにフォールバックします。 継承された config/backend は、今後の起動に限り、その secondmate home のローカルなランタイムバックエンドのデフォルトになります。すでに稼働中のワーカーエンドポイントの参照先変更、書き換え、移行、停止、再起動は行いません。 primary に値が設定されている場合は、検証済みの secondmate home に常にバイト単位で完全一致するよう収束させます。primary に値がない場合は、宛先側のコピーを削除し、各 home がランタイムの自動検出を維持するようにします。 明示的な起動ごとの --backend と FM_BACKEND は、各 home のローカルな config/backend より常に優先されます。これは継承されたデフォルトに対しても同様です。 宣言された config/supervision-host-off のオプトアウトも、同じく primary を正として伝播します。このファイルが存在する場合、secondmate home に独自のエンジン設定があっても、その home は対象外になります。存在しない場合は、収束時にそのコピーを削除します。 config/supervision-host 自体は継承されません。各 home がそれぞれのエンジンを選択します。 config/secondmate-harness は、secondmate エージェントの起動に使う primary 側の設定にすぎないため、継承されません。 config/firstmate-role は、primary のファイルをそのままコピーするのではなく、追加の解決済みロールとレシートのポリシーに従って継承されます。 アカウントの固定設定は継承されません。 docs/configuration.md「Per-secondmate account pins」では、明示的な config/secondmate-accounts/<id>/ のオーバーライドと、各 mate の home 内にある個別のワーカー固定設定を定めています。 data/captain-shared.md は primary home を正とし、secondmate home では読み取り専用です。 primary 側のファイルヘッダーには、このファイルが primary を正とすること、secondmate home では読み取り専用で編集してはならないこと、新たに発見した captain の嗜好は、ステータスへの印付けまたはドキュメントへのポインターを通じて main firstmate に伝えることを明記する必要があります。 伝播のたびに secondmate 側のコピーを primary のバイト列に収束させます。primary 側のファイルが存在しない場合は、既存の secondmate 側のコピーを隔離して削除し、不在の状態にも収束させます。 ローカルヘルパーとリモート受信側は、宛先をそれぞれが最後に公開した世代と比較します。そのため、変更されていない継承コピーは、ドリフトとして報告されずに静かに置き換えられます。 宛先が primary のバイト列にも、記録された世代にも一致しない場合は、置き換え前に、衝突を避けられる非公開の日時付き兄弟ファイルへ隔離します。ローカル経路では、home と隔離先の成果物を示す SECONDMATE_SYNC: 診断を出力するため、実際のローカル編集や公開の中断があっても復旧用コピーが残ります。 このヘルパーは、安全でないディレクトリ、シンボリックリンクが設定されたファイルや通常のファイルではないソースまたは宛先の成果物、およびハードリンクされた宛先ファイルを拒否します。 伝播処理の間、secondmate 側のコピーはファイルシステム上で読み取り専用です。ヘルパーは、保護された更新を行う間に限り、自身が所有する宛先を書き込み可能にし、成功時、バイト列に変更がない場合、回復可能な失敗時に、読み取り専用の状態へ戻します。 secondmate の data/captain-shared.md を primary にコピーして戻すことは、決してしないでください。 各 home の data/captain.md は、その領域固有の内容として維持してください。 既存の home への最初の伝播後、その home のローカルな data/captain.md を手作業で、領域固有の内容と data/captain-shared.md へのポインターに整理してください。非公開の内容を自動化して削除したり、黙って削除したりしないでください。 各 data/learnings.md は、captain の判断により完全にローカルな状態に保ってください。フリート全体に関わる仕組みの知見は、共有 learnings の伝播を新たに設けるのではなく、通常の firstmate リポジトリ経路を通じて追跡対象のドキュメントに反映してください。 エージェントは起動時に指示を新たに読み込むため、起動時や再起動時に AGENTS.md を再読込させる必要はありません。再読込が必要なのは、ブートストラップ一括処理が稼働中 home の指示面を更新する場合だけです。 ブートストラップで AGENTS.md の再読込指示を正常に送信した場合は BOOTSTRAP_INFO: として報告し、送信に失敗して再試行が必要な場合に限り NUDGE_SECONDMATES: を出力します。 継承された config/* の素材が稼働中の secondmate に対して変更された場合は、設定内容を文字どおり再読込させる別の指示が必要です。 ローカル home では、許可リストにある設定の書き込みが成功するたびに、ロックされたブートストラップ収束経路とセッション中の bin/fm-config-push.sh の両方が、共有の伝播レポートを使って、検証済みの書き込み後の宛先バイト列から、home ごとに世代固有の非公開指示ファイルを1つ作成します。対象は、その home で実際に変更された宣言済みの設定項目だけで、宣言順に並べます。 変更されたパスはそれぞれ、明確な開始・終了の区切りとともに、宛先ファイルの新しいバイト列全体を解析せずにそのまま表示します。伝播によって宛先コピーが削除された場合は、明示的なトークン ABSENT を表示します。 指示には、それらがデフォルトまたはルールであり、判断を妨げるものではないという最小限の説明だけを含めます。SHA 値、選択されたプロファイル、解析済みの要約、その他の生成された解釈は含めません。 data/captain-shared.md は設定ファイルではないため、この指示ファイルやメッセージに内容をインライン展開することは決してありません。 許可リストにある設定ファイルがすべて変更されず、再試行も保留されていない home には、設定再読込メッセージを送信しません。 プッシュ前の宛先バイト列に応じて、home ごとに変更されたファイルの集合は異なる場合があります。 配信には既存のルーティング済み secondmate 経路（fm-send）を使い、単一行のポインター CONFIG_REREAD: <absolute generation-specific instruction path> のみを送信します。指示ファイルの公開に失敗した場合は、可能な限り生成済みの正確なバイト列を上限付きの非公開再試行キューに保持します。以前の形式の再試行レポートも復旧可能な状態に保ちます。公開または再試行マーカーの書き込みに失敗した場合は、配信できるまでその世代を保持します。送信に失敗した場合は、可能な限り世代ごとの永続的な再試行マーカーを記録します。また、実行中のエージェントがすでに値を再読込したと誤認させることなく、すべての失敗について具体的な CONFIG_REREAD: 診断を出力します。 伝播、世代の公開、ポインターの配信の一連の処理では、home ごとの継承ロックを1つ保持します。そのため、セッション中のプッシュが並行しても、新しい世代の後に古い世代が配信されることはありません。 新たに起動または再起動された secondmate は起動時にすでにファイルを読み込んでいるため、保留中の設定再読込世代は破棄されるか、クリーンアップに失敗した場合は隔離されます。起動後に伝播によってファイルが変更されない限り、稼働中のエージェントに余分な設定再読込の指示を送る必要はありません。 再起動前に隔離された世代は、上限付きの非公開履歴に保持されます。また、クリーンアップ時に空の隔離世代が作成されることはありません。 配信済みの世代は、home ごとの上限付き状態履歴にのみ保持されます。保留中の世代は、配信が成功するか、起動によって置き換えられるまで保持されます。 リモート home は、fm-remote-inherit.sh を通じて同じ許可リストのバイト列を受け取ります。転送または追跡対象の指示面の変更により再読込が必要な場合、または以前の再読込が未完了の場合、収束の成功後に印付きの再読込指示を1つ受け取ります。 変更のない転送、または AGENTS.md、bin/、.agents/skills/ 以外での追跡対象の更新では、新たな再読込の必要性は生じません。 親側は、配信前にその指示を記録します。送信失敗、一部のみの適用、完了状況が不明な場合、または報告前に処理が強制終了された場合も指示を保持し、ロックされたブートストラップ収束処理で同じ経路を再試行します。 fm-secondmate-nudge-lib.sh は、永続的な指示記録と互換動作を所有します。 リモートホスト上には存在し得ない primary ローカルの世代ファイルへのポインターは送信しません。 継承されたハーネスやランタイムバックエンドのデフォルト設定を理由に、これらのデフォルトと異なる意図的なランタイム選択を拒否するよう fm-spawn を厳格化してはいけません。 ワーカー起動環境の契約では、明示的な環境変数の許可を別途定めています。 すでに稼働中の secondmate に対して、追跡対象ファイルの早送りを行わずに、セッション中の継承ローカル素材の変更をプッシュする場合は bin/fm-config-push.sh を使用してください。 このスクリプトは、ブートストラップと同じ稼働中 home の検出および伝播ヘルパーを使い、各項目を pushed、unchanged、skipped、error のいずれかとして報告します。また、変更された世代や保留中の世代について、上記の設定再読込の契約に従います。 bin/fm-home-seed.sh は、存在しない charter またはプレースホルダーの charter のコピーを拒否します。 既存のブリーフがない直接シードには FM_SECONDMATE_CHARTER が必要です。 レジストリの整合性を確認するときは bin/fm-home-seed.sh validate を実行してください。完全な検証と拒否の仕組みはそのヘッダーが担っています。

シードはトランザクションとして実行されます。 検証、クローン、no-mistakes の初期化、またはレジストリの更新が失敗した場合、生成されたブリーフ、新しいホーム、新しいプロジェクトのクローン、およびレジストリの編集はロールバックされます。

セカンドメイトのプロジェクト一覧には、no-mistakes および direct-PR プロジェクトのみを含めることができます。 local-only プロジェクトはメインのファーストメイトに残ります。 no-mistakes プロジェクトの場合、シードはセカンドメイトのホームに新しくクローンされたプロジェクトのみを初期化し、すでに初期化されていない既存のクローンを変更することを拒否します。

既存または継承したドメインの記録の取り込み

シードの前にドメインを分類してください。この手順は2つのケースのうち1つにのみ適用されるためです。 グリーンフィールドのドメインには、まだ提供されたドメイン作業がありません。プロジェクトですでに出荷されたもの、稼働中のデプロイ、インポートすべき前任者の記録のいずれも存在しません。 グリーンフィールドのドメインは通常どおりシードしてください。突き合わせるものは何もなく、このセクションがそこに作業を追加することはありません。 既存または継承したドメインとは、製品がすでに開発中であるあらゆるドメイン、および新しいメイトが引き継ぐ前任者のドメイン（引退後の統合を含む）を指します。 これらのケースはいずれも、新しいメイトが継承した計画に基づいて行動する前に、記録の取り込みを必要とします。

既存または継承したドメインの場合、作成するエージェントは次のことを行わなければなりません。

1. 継承したすべての計画を、ドメインの権威ある出荷済み状態、すなわち関連する各プロジェクトの origin/main と稼働中のデプロイに対して突き合わせてください。 関連する各プロジェクトのフェッチ済みクローンは、その突き合わせの前提条件です。したがって、最初のタスク時ではなく、突き合わせの前にホームをそのプロジェクトに接続してください。 インポートされたバックログ、前任者自身のメモ、指示面の文章、および存在しないかフェッチされていないローカルのビューは、いずれも出荷済み状態の証拠として認められません。
2. 新しいホームには、真に未解決の作業と、ドメインの永続的な知識、すなわちまだ有効な学び、決定、およびデリバリーの姿勢のみをシードしてください。
3. 計画のバックログを盲目的に継承してはなりません。 作業がすでに出荷済みである計画行は削除するか、それを確定させるマージ済みの証拠とともに完了として記録し、未解決として引き継いではなりません。

稼働中のバックログは、設計上、設定された直近の Done エントリのみを保持します。そのため、継承したキューは構造的に計画を過大に表し、デリバリーを過少に表します。 対応するデリバリー記録を持たない計画を抱える継承キューは、未解決の作業としてではなく未突き合わせとして扱い、突き合わせできなかったものはすべて、新しいホームに明示的な残存不確実性リストとして記録してください。そのギャップを黙ったままにしてはなりません。

バックログの引き継ぎ

作成または引き継ぎの前に、AGENTS.md のセクション 10 にある「作業項目のみ」のバックログ契約を適用してください。 ドメインに secondmate を作成した場合、そのスコープに該当する既存のメインバックログ項目は、メインバックログに置き去りにせず、secondmate の作業にしてください。 スコープに該当するかどうかは、キーワード規則ではなく、自然言語で記述された secondmate のスコープに基づく firstmate の判断です。 data/backlog.md を読み、新しいスコープに合うキュー済み項目を選び、次のコマンドで移動してください。

bin/fm-backlog-handoff.sh <secondmate-id> <item-key>...

項目を移行した後、新しい secondmate のスコープ内にあるキュー済み項目について、この引き継ぎを実行してください。 既存のドメインまたは引き継いだドメインでは、すでに出荷済みの計画行が未完了作業として引き継がれないよう、先に記録の取り込みを完了してください。 ローカルルートの場合、ヘルパーは data/secondmates.md から secondmate のホームを解決して検証し、バックログ形式を一元管理する tasks-axi mv に項目の移動を委任します。このコマンドは、指定された各項目と、ブロッカーおよび依存項目から成る関連一式全体を、メインの data/backlog.md から secondmate のホームの data/backlog.md へアトミックに移動します。 リモートルートの場合、同じヘルパーがまず依存関係を閉じた一式をメインバックログから data/handoff/<id>.outbox.md にアトミックに移動し、その後、バックログ形式のアウトボックスを fm-on.sh 経由で転送します。さらに、リモートホームの fm-backlog-receive.sh が、宛先ロック下でまだ存在しないキーをすべて移動します。 新しいローカル配置、またはリモートアウトボックスの受領が永続化された後、ヘルパーは受け取り側 secondmate の登録済みエンドポイントに、ルーティングされた作業指示を 1 回送信するよう試みます。 bin/fm-backlog-handoff.sh は、ルートごとの起動結果、受領の永続化後のリモートアウトボックスの解放、安定した起動相関 ID の再試行動作を管理します。 2 フェーズの引き継ぎジャーナルはなく、すでに必須となっているアトミックな mv 機能以外に tasks-axi release もありません。 ミューテーションが許可されている場合、ブートストラップは保留中のアウトボックスと起動を再試行し、残っているアウトボックスがあれば SECONDMATE_HANDOFF: を出力します。 日常的な firstmate のバックログ編集のみを制御する config/backlog-backend=manual の場合も、この委任ルートは必須です。 各キュー済み項目のブロック全体、つまり - [ ] <id> ... ヘッダーと、それに続く 2 つ以上のスペースでインデントされたすべての本文行および空行の区切りを、次の項目またはカラム 0 のセクション見出しまで、同じセクション内でバイト単位に正確に移動します。これにより、インデントされた ## ... 行はセクション境界ではなく本文として扱われ、ヘッダーも本文も重複したり孤立したりしません。 単一スペースまたはタブでインデントされた継続行がある選択項目は、メインバックログに内容を孤立させるリスクを避けるため、移動を拒否します。 スコープ内の ## Queued エントリーのみを受け付け、## In flight および履歴上の ## Done エントリーは拒否します。 完了記録は、整理またはアーカイブのために各ホームに残してください。 この処理は冪等です。すでに secondmate のバックログにある項目はスキップされます。 移動が成功した後、main/<key> に紐付いた公開リレーへの返信がまだ必要な移動済みキーがあれば警告します。この紐付けは作業を担当するホームを指さなくなるためです。fmx-respond の確約済み最終応答手順を通じて、確約を secondmate:<id> に再バインドしてください。これらのコマンドの管理元は fmx-respond です。 同じルールは一般的なルーティングにも適用されます。作業が secondmate に送られる Relay リンク付きリクエストでは、ホームローカルのメンションリンクは使用できず、その secondmate のホームに紐付いた確約済み最終応答が必要です。 安全な運用ディレクトリと一致する .fm-secondmate-home マーカーを備えた、正式に初期化済みの firstmate ホーム以外を宛先に指定すると、処理は拒否されます。そのため、プロジェクトに項目が移動されることはありません。 local-only 項目は引き継がないでください。

リカバリー

ウィンドウがないローカルの kind=secondmate メタについては、secondmate を終了した永続的な直接レポートとして扱い、次のコマンドで再起動します。

bin/fm-spawn.sh <id> --secondmate

メタに記録された home= を使用します。 メタが見つからなくても data/secondmates.md に secondmate の登録が残っている場合は、レジストリーのエントリーとその永続ホームから再起動します。 リモートルートの場合、同じコマンドで設定済みのホストのみを調査し、必要な場合にのみ再起動します。 SSH トランスポートの障害や読み取れないリモートエンドポイントは不明のままとし、そのホスト上で照合する必要があります。ローカルの代替を起動してはいけません。 stuck-crewmate-recovery の remote-secondmate に関する注記では、エンドポイントの停止や送信失敗という判定が、これを正当化するように見えても、なぜそれ自体が信頼できないのかを説明しています。 再起動時には、現在の設定から secondmate のハーネスを再解決し、ガード付きの同じ起動前同期を行って、継承されたローカルの内容を再適用します。そのため、ホームが検証されると、復旧した secondmate の継承設定項目と共有キャプテン設定は収束します。追跡対象ファイルの同期には、別途ガードが適用されます。 secondmate がすでに実行中で、継承されたローカルの内容だけが変更された場合は、再起動するのではなく bin/fm-config-push.sh を優先してください。 稼働中のローカル secondmate を、新たに固定したハーネス、モデル、またはエフォートに移行するには、config/secondmate-harness を設定してから、bin/fm-control.sh <id> relaunch で再起動します。これにより、固定値を再解決し、エージェントを停止して、同じホームで置き換えのエージェントを起動します（docs/agent-control.md）。 同じ再起動およびリカバリーの経路では、永続的なsecondmate ごとのアカウント固定も適用されます。 この制御プレーンでは、別のホスト上でエージェントが実行されており、制御プレーンの事後条件を読み取れないため、名前を指定してリモートに配置された secondmate を拒否します。 リモートの secondmate を移行するには、bin/fm-remote-secondmate-relaunch.sh <id> <harness> <model|default|-> <effort|default|-> を実行します。これはそのホスト上で同じ制御プレーンによる再起動を行い、その後、ホストが確認した ID から、このプライマリ自身のルートメタデータを再公開します。プロファイルを明示的に渡し、固定値がない場合は default を使用してください。config/secondmate-harness は継承されず、そのホスト上のコピーは別のホームに属しているためです（docs/remote-secondmates.md）。 この用途で fm-on.sh を介して fm-remote-secondmate-control.sh relaunch を直接呼び出してはいけません。そうすると、このプライマリ自身の記録には、mate が実行に使用したランタイムが残ってしまいます。 更新が成功すると、両方の配置先にある稼働中の mate はすべて、それぞれの配置先で再起動されます。対象コミットにすでにいる mate も含まれます。この処理は /updatefirstmate スキルが担当し、永続化のゲートと失敗時の用語は bin/fm-secondmate-restart.sh が担当します。

メインホームから secondmate のツリー全体を再構築してはいけません。 メインの firstmate が照合するのは直接のレポートだけです。 各 secondmate は独自のホームを持つ firstmate であるため、起動時にリカバリーを実行し、自身の crewmate を照合します。 secondmate のリカバリーでは、すでに自身に属する作業のみを照合してから、待機状態になります。 リカバリー中に調査や監査を開始することはありません。

退役とティアダウン

secondmate はデフォルトで永続します。 キューが空でも正常な状態であり、ティアダウンは実行されません。 kind=secondmate の場合に限り、キャプテンまたはメイン firstmate がその永続的な secondmate の退役を明示的に決定したときだけ、bin/fm-teardown.sh <id> を実行してください。

安全性の確認対象は secondmate 自身のホームです。 state/*.meta に処理中の作業が含まれている間は、ティアダウンを拒否します。 強制でない退役では、その ID の親側の未解決の返信待ちが残っている場合も拒否します。 リモートルートでは、処理中かどうかの確認を設定済みのホストに委ね、さらにプライマリにハンドオフ待ちのアウトボックスがある間は拒否します。 SSH の終了コードが 255 の場合、リモート側の処理完了が不明なため、ルートとローカルの記録を保持します。 退役を進める際、ティアダウンは直接のエンドポイントを終了し、その ID の親側の返信待ち記録を未解決のものも解決済みの残存記録もすべて削除し、その配信確認を削除して、data/secondmates.md のルートを削除し、メインホームのメタデータを消去して、退役する secondmate のホームを削除します。 エンドポイントを終了できなかった場合、そのエンドポイントを示す記録を削除する前に退役を中止します。これにより、ディスク上にエンドポイントを示す情報が何も残っていないのに、エージェントがまだ稼働している可能性がある状態でクリーンアップが成功と報告されるのを防ぎます。 --force は退役する secondmate 自身のエンドポイントについてのみ、この中止を回避します。強制クリーンアップ中の子エンドポイントには適用されません。また、強制実行を続行する場合でも、後で自分で整合する必要があるエンドポイントが示されます。各バックエンドが自身の終了について証明できる内容は、docs/verification/runtime-backends.md の「Endpoint close」が規定します。 リースされたホームを削除すると、treehouse return によって永続的なツリーハウスのリースが解放されるため、プールのスロットはリースされたまま残らず、再利用できるようになります。 プールのスロットを持たない単純なクローンのホームは、そのまま削除されます。 リースされたホームで treehouse return が失敗した場合、ティアダウンは状態を保持したまま中止します。ディレクトリを直接削除して、保持中のリースを隠すことはありません。 返却または直接削除の前に、ティアダウンは対象ホームのプロセスイベントランナーに、安全な世代バインド方式を通じて登録と、マシン全体にわたり物理的に所有するクレームを退役させるよう要求します。 そのクリーンアップの結果が不確実な場合、またはクリーンアップを利用できない場合は退役を拒否し、後で再試行できるようホームと退役記録を保持します。 プロセスイベントの子プロセスがホームの削除後も存続する可能性があるため、直接削除はサポートされていません。

--force を指定すると、ティアダウンは明示的な破棄経路になります。 bin/fm-teardown.sh のワークツリースロット所有権の契約は引き続き適用されます。--force を指定しても、別のタスクが所有している可能性のある子孫のプールスロットを返却することは許可されません。 子ウィンドウを終了し、secondmate ホーム内の子の作業と状態を破棄し、ルートを削除し、リースを解放して、退役する secondmate のホームを削除します。 強制ティアダウンの対象となるホームで新しいタスクの公開と競合した場合、1 つのコマンドはタスク状態を公開も削除もせずに拒否されます。この拒否は終端状態として扱い、再試行する前にもう一方の操作を確認してください。 fm-spawn.sh --relaunch と強制でないティアダウンは、このタスクセットの直列化の対象外です。自動復旧の直列化については、fm-secondmate-liveness-lib.sh のヘッダーが規定します。 キャプテンが作業を破棄するよう明示的に指示しない限り、--force は絶対に使用しないでください。