expected-failures.yml

# Conformance scenarios not yet passing against the Python SDK on main.
# CI exits 0 if only these fail, exits 1 on unexpected failures or stale entries.
#
# Baseline established against the harness pinned via CONFORMANCE_PKG in
# .github/workflows/conformance.yml. New conformance releases are adopted by
# deliberately bumping that pin and reconciling both this file and
# expected-failures.2026-07-28.yml in the same change.
#
# Entries are grouped by SEP. As each SEP lands in the SDK the corresponding
# scenarios start passing and MUST be removed from this list (the runner fails
# on stale entries), so the baseline burns down per milestone.

client:
  # SEP-1932 (DPoP): the SDK's OAuth client does not implement DPoP proofs.
  # The entries are per-check (conformance #406) because both scenarios
  # pass their non-DPoP checks (discovery, token acquisition, request
  # flow) live.
  - auth/dpop:sep-1932-client-token-request-proof
  - auth/dpop:sep-1932-client-dpop-auth-scheme
  - auth/dpop:sep-1932-client-fresh-proof
  - auth/dpop-nonce:sep-1932-client-token-request-proof
  - auth/dpop-nonce:sep-1932-client-dpop-auth-scheme
  - auth/dpop-nonce:sep-1932-client-fresh-proof
  - auth/dpop-nonce:sep-1932-client-as-nonce
  - auth/dpop-nonce:sep-1932-client-rs-nonce
  # Workload identity federation: the OAuth client does not implement the
  # urn:ietf:params:oauth:grant-type:jwt-bearer grant (it answers with
  # authorization_code). Per-check for the same reason.
  - auth/wif-jwt-bearer:wif-grant-type

server:
  # SEP-2663 (io.modelcontextprotocol/tasks): the SDK implements the extension
  # with tasks born terminal — the tool runs to completion inside the
  # interceptor, so there is no background execution and no in-task
  # `input_required` parking (see the deferred follow-ups in
  # src/mcp/server/tasks.py). tasks-mrtr-input needs exactly that surface: a
  # task that parks with `status:"input_required"` + a non-empty
  # `inputRequests` map on tasks/get, resumes via the tasks/update
  # inputResponses loop, and supports partial fulfillment across two pending
  # keys. The everything-server's `confirm_delete`/`multi_input` fixtures
  # therefore resolve their elicitation on the original `tools/call` (SEP-2322
  # MRTR) and never mint a task, so all three checks fail with "did not create
  # a task". Remove this entry when background task execution and the in-task
  # input_required/tasks/update resume loop land. Extension-tagged scenarios
  # are selected only by the bare `--suite all` leg — they never match a
  # --spec-version filter and the active/draft suites exclude them — so this
  # entry is inert for the other legs that read this file.
  #
  # `tasks-status-notifications` is intentionally NOT listed: the harness
  # skips it unconditionally (pending its rewrite against subscriptions/
  # listen), and a baseline entry for a scenario with no failing checks is
  # flagged stale. The other eight tasks-* scenarios pass against the
  # everything-server's Tasks registration and are not listed either.
  - tasks-mrtr-input