ターンパイプライン

Asterel でコンパニオン・ターンを実行する表面は、同じターン契約に合流します。これは言うのは簡単ですが、維持するのは高コストです。そして継続性の主張の機械的な背骨でもあります。Discord テキストはプロダクトとして検証中の主チャネルです。他のチャネルや運用者画面も、ターンを作成または再生するときにこの契約を再利用します。ただし、すべてが同じ成熟度のプロダクト表面ではありません。

共有経路

受理したターンDiscord · CLI · ゲートウェイ · 運用者画面

拾い上げ / 入力方針
入力イベントをターンに昇格させるかをまず判断します。
ターン事前補強
感情検出 · 記憶想起 · 人格文脈
応答組み立て + ツールループ
ツール呼び出しは下記のミドルウェア列を通ります。
Critical step:送信前検証
省略不可。ここを通ったターンだけが状態に折り込まれます。
返信配信
ターン後更新
関係記憶 · 人格の揺れ · 継続性の手がかり

トランスポート向けの経路は src/runtime/services/companion_turn.rs にあります。ターン前後の補強は src/core/agent/turn_enrichment/ が所有します。既定のツールループはすべてのツール呼び出しを次のミドルウェア列に通します。

SecurityMiddleware → HookMiddleware → EntityRateLimitMiddleware → AuditMiddleware
  → SemanticCompactionMiddleware → ToolOutputCompactionMiddleware
  → OutputSizeLimitMiddleware → ToolResultSanitizationMiddleware
  → SecretScrubMiddleware → TaintMiddleware

共有契約にする理由

プロジェクトが統一の維持コストを払う理由は三つあります。

継続性が表面ごとに静かに分岐してはいけない。 Discord 側の補強と CLI 側の補強がずれると、コンパニオンは話す場所によって別の存在になります。ランタイムはその失敗を防ぐためにあります。
検証はチョークポイントであり、飾りではない。 送信前検証は省略可能であってはいけません。第二のパイプラインは、それを実行し忘れる第二の機会になります。
振る舞いが再現可能になる。 同じ受理ターンは、発生元に関係なく同じコードを通ります。これにより評価、再生、インシデント調査が可能になります。そうでなければ表面ごとに別のデバッグ面になります。

入力方針はエッジにある

すべての入力イベントがターンになるわけではありません。補強の前に走る拾い上げ / 入力方針が次を判断します。

このメッセージはコンパニオンに向けられているか、それとも周辺の雑談か
コンパニオンはこのチャネルで最近すでに十分話していないか
部屋は公開、私的、スレッドのどれで、それによってコンパニオンが保つべき距離は変わるか

この判断は記憶想起と人格文脈の前に置かれています。すべての入力イベントに補強を走らせるコンパニオンは予算を消費し、前のめりで境界のない存在に見えます。拾い上げゲートは性能上の制約であると同時に、キャラクター上の制約でもあります。

ツールループは副手順であり、中心ではない

ターン途中でツール呼び出しが必要な場合、ツールループは応答組み立ての内部で回ります。統制され、監査され、レート制限され、汚染追跡されます。これはユーザーから見たターンの形には漏れません。ツール呼び出しがあるターンもないターンも、同じ送信前検証と同じターン後更新を通って出ます。

これは意図的です。「今はエージェント、今はチャット」と見える形でモード切り替えするコンパニオンは、二つの人格を持っているように見えます。Asterel は一つのコンパニオンとして振る舞います。