WIP: generic scenario steering — plumbing-only client scenarios shouldn't need per-SDK fixture handlers
メンテナーはふだん 7 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- typescript
- 領域
- testing
調査の方向性
まず #51 で説明されているコンテキスト引き渡しチャネルを読み、次に #335 の SDK ごとに動作するハンドラーと、#345 で指摘された差異を確認します。シナリオステップの汎用データとインタープリターの境界を定義しつつ、実際のクライアント動作が必要なシナリオについては専用ハンドラーを維持します。シナリオごとのハンドラーを変更せずに、plumbing のみを必要とするシナリオを SDK の fixture 全体で実行できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Parking a design note; details to be fleshed out (there may be an earlier exploration of this on a branch elsewhere — to be dug up and linked).
Pain (fresh example from #335)
All five Tier 1 SDK conformance clients failed the new json-schema-2020-12-preservation scenario with "Unknown scenario" — yet when we prototyped the missing handler in each fixture (10-35 lines each), every SDK passed 9/9. The scenario needs no SDK behavior change at all; the per-scenario fixture handler is pure dispatch plumbing, duplicated across N repos, and it rots (see #345 for in-repo drift of the same kind).
Idea
Scenarios of this shape declare their client-side steps as data over the context-passing channel from #51 (implemented), e.g. steps like "tools/list", "call tool X with the schema you got for tool Y". Each SDK fixture implements one small generic interpreter, once; after that, new plumbing-only scenarios need zero fixture changes anywhere. Scenarios needing real client behavior (elicitation decisions, sampling, auth flows) keep bespoke handlers.
Related: #51 (context channel), #345 (handler drift), #335 (motivating case, with working handler patches for all five SDKs).
- 主要言語
- TypeScript
- スター
- 130
- フォーク
- 107
- 平均マージ
- 8日 19時間
- マージ済み PR（30日）
- 2
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/conformance のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
modelcontextprotocol/conformance#531 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
-
server-stateless: 500 ms whole-request deadline in no-log-without-loglevel reports slow servers as failures対応中かも @birbprophet が 10 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/conformance#530 ·
メンテナーはふだん 7 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
modelcontextprotocol/conformance#519 ·
メンテナーはふだん 7 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
modelcontextprotocol/conformance#315 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/conformance#312 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
modelcontextprotocol/conformance の issue をすべて見る
似ている issue
-
refactor
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
tomnewport/memprot-topo#55 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
WalletConnect/walletconnect-monorepo#7368 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
BU-Spark/se-chem-apll#47 ·
-
embed: handleTurboSignMessage header comment says the signing page posts to '*' (it never does)オープンdocumentation
難易度 2/5 1時間未満 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 半日 初心者へのやさしさ 70/100
udistrital/paginaweb_root#23 ·