Expose expected-vs-emitted check coverage per scenario
メンテナーはふだん 7 日以内に返信
@AmirK-S がすでに取り組んでいます。
2026年9月29日 から。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 48/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- cli, testing-qa
調査の方向性
Scenario と ClientScenario がチェックをどのように定義または実行するかを追跡し、次に結果の構築を terminal のサマリーと machine-readable output までたどってください。まず setup-failure と passing thin-scenario のケースを確認してください。完了とは、対象となる expected coverage と emitted coverage が一貫して報告され、applicability gates が誤った欠落を生み出さず、両方のケースにテストがあることを意味します。
索引モデルが issue の本文から書いたものです。
説明
A scenario can emit only a thin subset of its checks while the reported denominator makes that subset look complete.
The concrete case from mcpkit: auth/authorization-server-migration reported 2 passed, 1 failed for months. The initial wire handshake failed, so roughly 76 other checks never emitted. PR #327 makes the setup failure explicit, but the result still cannot show how much of the scenario did not run.
The harder case has no setup failure: setup succeeds, only accept-path checkpoints emit, and the thin scenario result passes.
Add a per-scenario expected-vs-emitted coverage signal to the upstream results. It should be visible in both terminal summaries and machine-readable output. A count is enough to expose the gap; stable IDs would also identify the missing checks.
Today Scenario and ClientScenario do not declare their expected check IDs, and some checks are dynamic or version-gated. The implementation will need a stable expected set or another baseline that excludes checks which are not applicable to the selected spec version or extension.
Acceptance criteria:
- Every executed scenario reports expected and emitted check counts, or equivalent coverage data.
- Missing eligible checks remain visible when every emitted check passes.
- Machine-readable results expose the coverage signal for downstream consumers.
- Spec-version, extension, and documented applicability gates do not create false gaps.
- Tests cover both a setup failure and a passing thin-shadow result.
- SDKs do not need to maintain their own per-scenario count snapshots.
@panyam offered to implement this in #327.
Prior art: https://github.com/panyam/mcpkit/pull/1115
- 主要言語
- 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 が 8 日前に担当しました。 オープン
難易度 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
-
level/task reporter/qa type/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
wazuh/wazuh-dashboard-plugins#9310 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
cybersemics/treecrdt#267 ·
-
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
wiz-sec-public/backstage-plugin-wiz#16 · コメント 1 件 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
solana-foundation/solana-com#2245 ·
メンテナーはふだん 1 日以内に返信