Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

A coworker created as Built in still cannot hand work on

オープン
  • 何か問題がありますか？
#399 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #695 @Harbor404 による — マージされずにクローズ

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
typescript
領域
backend-api-design

調査の方向性

#317 の延期された設計と #331 に記載された動作を読み、その後 plugins/store.ts、特に agentRunsHere と managedConfiguration のパスを調べてください。endpoint のない built_in ストレージオプションと、callback surface 上で hop endpoint を mint する方法を比較し、既存の managed Bot があるデプロイメントと、すでに remote_ag_ui として保存されている同僚に対して選択した動作を文書化してください。

索引モデルが issue の本文から書いたものです。

説明

Tracking the design question #317 deferred on purpose, so it survives the PR that half-answers it.

From that PR's description:

A coworker created as "Built in" through the wizard is stored as remote_ag_ui pointed at the
managed endpoint. Its tool callbacks work (the deployment-token path), but the handoff tool is
minted only inside this deployment's own run loop, so such a coworker can be asked but cannot
itself hand work on. […] Fixing it properly means either storing endpoint-less creates as
built_in type, or adding a server-minted hop endpoint to the callback surface — worth its own PR
either way.

What #331 covers

#331 takes the first option, because the interview it adds cannot end by asking somebody for a URL.
store.create writes a built_in coworker running on its role description where there is neither
an endpoint nor a managed Bot — which on the one-container image the README recommends is every
coworker.

That buys back exactly what the note was about, in that case: agentRunsHere is
row.type === "built_in" (plugins/store.ts), and grantable on the handoff answer comes from it,
so a coworker created that way can be handed work on.

What is still open

Where the deployment does have a managed Bot, create still prefers managedConfiguration, the
row is still remote_ag_ui, and nothing changes: the coworker can be asked and cannot hand work on.
The wizard's "Built in" option is only offered on exactly those deployments, so the case #317
described is the case still outstanding.

Two ways out, both from the original note:

  1. Store endpoint-less creates as built_in even when a managed Bot exists. Smallest diff, and
    it makes "Built in" mean one thing everywhere rather than two things depending on configuration.
    The question is what happens to coworkers already stored the other way — they keep working, but
    the roster then holds both shapes with no way to tell them apart except the endpoint string.
  2. Mint a hop endpoint on the callback surface. Leaves storage alone and makes the handoff tool
    reachable from outside the run loop. Larger, and it puts a new server-minted address into a
    surface that currently only issues tokens.

Not proposing either — this is #317's question and the choice is its author's. Filing it so it does
not disappear when #331 merges and the no-managed-Bot half stops being visible.

主要言語
TypeScript
スター
6.6k
フォーク
914
平均マージ
19時間 22分
マージ済み PR（30日）
140

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CopilotKit/OpenBot のほかの issue

CopilotKit/OpenBot の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。