__version__.py

"""NullRun Platform SDK.

v3.31.5 / 0.14.6 (2026-08-01) — CI coverage-job flakefix +
actions.cooldown window-of-zero race.

Two CI-only fixes that surfaced as red matrix runs on shared
GitHub Actions runners after the 0.14.5 release:

1. ``.github/workflows/ci.yml:74`` — the ``coverage`` job install
   line now pulls ``pytest-rerunfailures>=14.0,<16.0`` alongside
   ``pytest-cov>=5.0``. The marker
   ``@pytest.mark.rerunfailures(reruns=2)`` on
   ``tests/test_approval_timeout_field.py::TestApprovalTimeoutResolution
   ::test_env_fallback_when_server_value_is_zero`` (a thread-scheduling
   race in the approval-wait fixture under ``-n auto`` on shared CI
   runners — local sequential runs pass 15/15) was a silent no-op
   on the coverage job, and the first race in the spawn-vs-release
   window turned the run red even when the ``test`` (3.10/3.11/3.12)
   matrix was fully green. The marker itself
   (``reruns=2``, ``release_after_ms=200``) was already in place
   from the Sprint 0 audit — the missing piece was the plugin on
   the coverage leg. This release matches the install on
   ``ci.yml:41-45``.

2. ``tests/test_actions.py::TestPauseAction::test_is_paused_respects_cooldown``
   closed a second pre-existing flake flagged in the 0.13.7
   changelog. The test asserted ``is_paused(..., cooldown_seconds=0.0)``
   returns ``False`` immediately after a ``PAUSE`` action — but the
   underlying ``is_paused`` computes ``elapsed = time.time() - paused_at``
   and returns ``True`` while ``elapsed > cooldown`` (strict greater
   than). On any platform where ``time.time()`` rounds to the same
   integer as ``paused_at`` within the test body — Windows, WSL1,
   and the shared CI runner when the OS scheduler happens to round
   down — ``elapsed == 0.0`` and the workflow stays "paused" forever,
   failing the assertion. Pre-0.14.6 this was rare-flaky
   (``1 in 1142`` per 0.13.7 changelog); on the 0.14.5 runner pool
   it became ``5 in 5``. The test now sleeps ``0.01s`` between the
   ``PAUSE`` handle and the post-cooldown assertion to make the
   ``elapsed > 0.0`` check deterministic. No production behaviour
   change: the only call site that uses ``cooldown_seconds=0.0`` is
   this test, and ``ActionHandler.is_paused`` is an internal helper.

Tests:

  * Full suite green on local ``pytest tests/`` after both fixes:
    1417 passed, 7 skipped, 10 warnings.
  * ``ruff check src/ tests/`` -- All checks passed.
  * ``mypy src/`` -- Success: no issues found in 37 source files.

No public API change. No on-wire change. No SDK_MIN_VERSION bump.

--

v3.31.4 / 0.14.5 (2026-08-01) — MCP metadata and tool-argument
forwarding.

This release completes the SDK-side path for MCP-aware gate
policies and schema-drift fingerprints:

  * ``set_mcp_tool_context`` stores the canonical tool class and
    MCP ``tools/list`` annotations in per-call context variables.
    ``NullRunRuntime.check_workflow_budget`` forwards populated
    values as optional ``tool_class`` and ``mcp_annotations``
    fields on ``/check``.
  * ``MCPAdapter`` wraps a connected synchronous MCP client,
    caches ``tools/list`` metadata for 300 seconds, normalises
    ``readOnlyHint`` / ``destructiveHint`` / ``openWorldHint``,
    stamps the context before each call, and delegates the call
    without changing the client's result or exception surface.
  * ``Transport.execute`` accepts optional ``tool_arguments``;
    ``Transport.check`` forwards the same field from its request
    mapping. The backend can use this JSON argument bag to compute
    and record a stable tool-schema fingerprint.

All new wire fields are optional and omitted when unavailable, so
existing callers and older SDK integrations preserve their prior
request shape. MCP annotations remain an honest-client signal;
the SDK does not independently verify a server's declarations.
The adapter does not implement MCP transports or JSON-RPC and does
not auto-collect arguments for arbitrary callers.

---

v3.30 / 0.14.4 (2026-07-27) — ToolParameters Approval Rules
wire contract (Tier 2 / Разрыв 2 follow-up).

Pre-fix 0.14.0, a ``track_tool`` event payload containing a
``Decimal`` (e.g. ``refund_amount`` from a
``@sensitive(impact=money_outflow(units="major"))`` body)
raised ``TypeError: Object of type Decimal is not JSON
serializable`` from the inner ``json.dumps`` call. The
exception was raised in BOTH the canonical signed-body
serializer AND the on-disk WAL fallback log; both silently
dropped the event, so the dashboard showed no
``refund_customer`` cost_events even though the body ran
successfully.

Fix (one-liner on each call site):

  * ``transport.py:251`` ``_signed_request_body(payload)`` now
    calls ``json.dumps(payload, separators=(",", ":"),
    default=str)``. Pre-fix events that serialised cleanly
    still serialise to the same bytes because ``default=`` is
    only consulted when the default encoder fails.
  * ``transport.py:711`` WAL fallback ``f.write(json.dumps
    (event) + "\n")`` also gets ``default=str`` for
    consistency. The on-disk fallback log is read by ops only
    when the backend is unreachable, so the wire-format
    guarantee does not apply here.

Decimal is now serialised as its lossless string
representation (``"50.99"`` on the wire), and the backend's
pricing math runs on the same string. Other non-JSON-native
types (``bytes``, ``datetime``, ``UUID``) get the same
``str()`` fallback so a single encoder pass handles them
all.

Verification:

  * ``_signed_request_body({"events": [{"type": "tool_call",
    "refund_amount": Decimal("50.99"), ...}]})`` returns a
    140-byte payload with ``"refund_amount":"50.99"`` on the
    wire. Pre-fix code raised ``TypeError`` at the same call
    site.
  * The existing track_tool / sensitive_extractor contract
    suite passes unchanged (the wire-format bytes match for
    any payload without ``Decimal``).
  * ``pytest tests/test_sensitive_extractor.py`` -> 5/5 pass.
  * ``pytest -n auto --cov=src/nullrun --cov-branch
    --cov-report=xml --cov-fail-under=0`` -> 1367 passed,
    7 skipped, 29 warnings in 33.24s, cov 81.49%.

Backward-compatible bug fix. No SDK_MIN_VERSION bump. No
public API change. The wire shape is preserved for every
pre-fix event (a non-Decimal payload serialises to the same
bytes); the Decimal serialisation is a strict superset.

---

v3.28 / 0.14.0 (2026-07-23) — hardening pass on the money contract.

Closes the four review gaps from the Phase 1.1 / UX follow-up:

  1. **Dedicated error types** -- ``InvalidMoneyPrecisionError``
     and ``InvalidMoneyAmountError`` (both subclass
     ``ValueError`` for backward compat). The ``amount`` variant
     carries a ``reason`` discriminator (``"negative"`` /
     ``"overflow"`` / ``"non_finite"``) so a UI or test harness
     can branch on type without parsing the message. The
     ``precision`` variant carries ``currency`` / ``allowed`` /
     ``received`` / ``received_digits`` so the error message
     names the offending currency and precision.

  2. **Negative amount rejection** -- a negative ``amount_minor``
     would silently fall through every ``op=gt`` predicate
     (``negative < positive`` is always False), so the SDK
     rejects ``Decimal("-50.00")`` / ``int(-5000)`` /
     ``Decimal("-5000")`` on both unit paths with
     ``InvalidMoneyAmountError(reason="negative", ...)``. ``0``
     is accepted (legitimate $0.00 refund).

  3. **Sub-precision Decimal rejection** -- ``Decimal("1.234")``
     against a USD ``allowed=2`` precision is now
     ``InvalidMoneyPrecisionError(currency="USD", allowed=2,
     received=3, received_digits="1.234")`` instead of a silent
     round to ``1.23`` that drops the high-order digit the user
     explicitly typed. ``float`` and ``Decimal`` are treated
     symmetrically; ``int`` always rounds 0-digits.

  4. **Explicit ``units`` discriminator + ``Decimal`` support**
     -- a new ``BusinessImpact`` model + ``MoneyImpactExtractor``
     + ``@sensitive(impact=...)`` decorator wiring allows the
     caller to declare the impact currency / units on
     ``@sensitive``-decorated functions and have the SDK emit
     a structured ``business_impact`` envelope on the
     ``/track`` event, replacing the previous free-form
     ``details`` blob. ``Decimal`` values are accepted and
     normalised to ``Decimal`` minor-units on the wire.

Side fixes (covered by the same audit pass):

  * ``/execute`` now handles ``require_approval`` correctly
    and re-checks with the ``approval_id`` returned by the
    backend (was dropping the approval handshake on
    round-trips).
  * Server's ``approval_timeout`` is clamped to ``[1, 3600]s``
    on the SDK side as defence against a malformed /
    overshooting backend that returns ``0`` or ``2147483647``
    in the Разрыв 1c field.

Public API change (additive only, backward-compatible):

  * ``InvalidMoneyPrecisionError``, ``InvalidMoneyAmountError``
    -- new ``ValueError`` subclasses with structured fields.
  * ``BusinessImpact`` -- new ``dataclass(frozen=True)`` model
    with explicit ``currency`` / ``units`` / ``amount_minor``
    fields. ``details`` dict is still accepted (legacy path).
  * ``@sensitive(impact=BusinessImpact(...))`` -- new
    decorator kwarg. Existing ``@sensitive(details=...)`` /
    ``@sensitive(amount_minor=..., currency=...)`` callers keep
    working on the happy path (now routed through
    ``BusinessImpact`` internally).

Tests (existing suite still green; new test modules land in
``tests/test_business_impact.py`` /
``tests/test_units_discriminator.py`` /
``tests/test_money_hardening.py`` /
``tests/test_sensitive_extractor.py`` /
``tests/test_approval_money_flow.py`` /
``tests/test_execute_approval_flow.py``):

  * 5 Definition-of-Done scenarios cover negative-amount
    rejection, sub-precision Decimal rejection, overflow
    rejection, non-finite rejection, ``0`` accepted.
  * Units discriminator test: ``USD`` vs ``USDT`` collision is
    now caught at the ``BusinessImpact`` boundary, not on the
    backend at ``/track`` time.
  * ``/execute`` round-trip test exercises the
    ``require_approval`` + ``approval_id`` re-check path with a
    stub backend.
  * Server ``approval_timeout`` clamp test verifies
    ``[1, 3600]s`` boundary.
  * 5 contract tests cover the ``MoneyImpactExtractor`` path
    end-to-end.

Verification (local):

  * ``pytest tests/test_money_hardening.py
    tests/test_business_impact.py tests/test_units_discriminator.py
    tests/test_sensitive_extractor.py
    tests/test_approval_money_flow.py
    tests/test_execute_approval_flow.py`` -- all new tests
    pass; no regressions in the existing suite.
  * ``ruff check src/ tests/`` -- All checks passed.
  * ``mypy src/`` -- Success: no issues found in 34 source
    files.

No SDK_MIN_VERSION bump (legacy backends unaffected). No on-wire
change (envelope shape preserved). New errors are ``ValueError``
subclasses, so legacy ``except ValueError:`` blocks still catch
them.

---

v3.27 / 0.13.13 (2026-07-21) — Разрыв 1c SDK sync.

Backend commit ``0ad03b9`` (Разрыв 1c, gate hot-path trigger)
added ``approval_timeout_seconds: Option<i64>`` and
``approval_expires_at: Option<String>`` to the GateResponse
wire format. Before this SDK fix, the approval wait path used
``NULLRUN_APPROVAL_TIMEOUT_SECONDS`` env default (default
300s) as the ONLY source of wait duration — which is exactly
the Разрыв 3 class of bug that the backend sweeper was written
to prevent on the backend side.

Concretely: a backend approval rule configured with
``expires_in_seconds=20`` (short-approval use case) would
have the backend's expiry sweeper close the row at 20s, but the
SDK would have timed out the parked gate call at 300s — a
silent desync. The 300s/300s coincidence worked only because
no UI-1 yet exists to set non-default expirations, and because
the env default matched the backend default.

Fix (no on-wire change, backward-compatible API):

  * ``runtime._wait_for_approval_resolution``: new optional
    kwarg ``timeout_seconds: float | None = None``. When set
    to a positive number, used as the event.wait() timeout
    (server-authoritative, takes precedence over the env
    default). When ``None`` (legacy backend without Разрыв 1c
    field, or malformed response), falls back to
    ``self._approval_timeout_seconds`` (env default) —
    pre-Разрыв 1c behaviour preserved. When set to a
    non-positive number (0 or negative), also falls back to
    env default; we explicitly reject these because
    ``event.wait(timeout=0)`` deadlocks on the very first call.

  * ``runtime.check_workflow_budget``: reads
    ``response["approval_timeout_seconds"]`` (server value),
    validates the type (must be a number) and sign (must be
    positive), and falls back to ``None`` on any validation
    failure. ``approval_expires_at`` is intentionally not
    parsed in the SDK (informational only; the SDK's wait math
    doesn't need it).

  * When the server value diverges from the env default, a
    DEBUG log line is emitted ("approval {id}: using server
    timeout={X}s (env default would have been {Y}s)") for
    diagnostic visibility.

Tests (existing suite still green; new tests in
``tests/test_approval_timeout_field.py``):

  * 6 new tests cover server-timeout-used, env-fallback on
    missing/zero/negative/non-numeric values, sentinel-
    returned-when-no-ws-push, and diverging-server-value
    log line. Pairs with backend commit ``0ad03b9``.

Verification:

  * ``pytest tests/test_approval_timeout_field.py`` —
    6 passed.
  * ``pytest -n auto --cov=src/nullrun --cov-branch
    --cov-report=xml --cov-fail-under=0`` —
    1243 passed, 7 skipped, 28 warnings in 34.44s
    (coverage 80.92%).
  * ``ruff check src/ tests/`` — All checks passed.
  * ``mypy src/`` — Success: no issues found in 34 source
    files.

Backward-compatible public API change. No SDK_MIN_VERSION bump.
No on-wire change.

---

v3.26 / 0.13.12 (2026-07-20) — CI / coverage-testability release.

The pytest suite now runs a `_fast_sleep` autouse fixture in
``tests/conftest.py`` that caps test-code ``time.sleep`` calls at
1ms, with two opt-out paths: ``@pytest.mark.slow_sleep`` on a
test/class (e.g. ``TestPingChainScheduler``) or the
``NULLRUN_FAST_SLEEP=0`` env var. The three
``TestCircuitBreaker`` half-open tests that previously used a
bare ``time.sleep(1.1)`` to wait out the 1.0s recovery_timeout
now drive the wall clock via a ``_advance_clock(monkeypatch)``
helper that patches ``time.monotonic`` instead — deterministic
across xdist workers and zero wall-clock cost.

Net effect: ``pytest -n auto`` coverage on master dropped the
3.3-second per-test wall-clock tax on ``TestCircuitBreaker``
(only on Windows where xdist is single-worker-bound) and the
suite goes from "almost-hangs" to ~35s end-to-end. CI scope only;
no on-wire change, no SDK_MIN_VERSION bump, no public API
change.

Coverage report (local): 80.79% combined (master 29caae9 was
reported as 79.26% by Codecov because the pre-fix CI uploaded a
coordinator-only 0% report; this release keeps the 80% floor in
``.codecov.yml`` and the new combined report is what the
Codecov badge will render against the master branch).

---

v3.25 / 0.13.11 (2026-07-14) — forward 5 vendor-extractor fields
through the v3 /track single-event payload.

Pre-fix (0.13.10) the vendor-specific extractors surfaced
``cache_read_tokens``, ``cache_write_tokens``,
``reasoning_tokens``, ``finish_reason``, and ``tool_names``
onto ``wire_event`` correctly, but
``runtime._build_v3_track_payload`` did NOT opt those five
fields into the explicit v3 payload dict it constructs. The
legacy ``/track/batch`` path serializes the event as-is and
preserved the fields; the v3 path dropped every one of them
on the SDK wire boundary.

Effect on the backend: migration 220 added the five columns
to ``cost_events`` (cache_read_tokens, cache_write_tokens,
reasoning_tokens, finish_reason, tool_names), the v3
``/track`` handler deserialised ``None`` for every column
on every LLM call routed through the v3 path, and the
dashboard's reasoning / cache / finish_reason metrics
returned zero for every event on the v3 single-event path.

Fix (no public API change, no wire-format change):

  * ``runtime._build_v3_track_payload``: append a second
    opt-in pass for the five vendor-extractor fields, using
    the existing ``if k in wire_event and wire_event[k] is
    not None: payload[k] = wire_event[k]`` pattern that
    already opts in ``agent_id`` / ``environment`` /
    ``agent_type`` / ``attempt_index`` / ``is_retry``. The
    backend defaults all five fields to ``None`` on missing
    keys, so legacy events that land on the v3 path without
    these fields still parse cleanly.

Wire format: unchanged. Backends on 1.0.0 keep working
unchanged. Pinning unchanged: SDK_MIN_VERSION_FOR_V3 =
"0.12.0". Recommended upgrade path: 0.13.10 -> 0.13.11.

Tests (existing suite still green; no new test files):

  * tests/test_v3_wire_contract.py — 36 tests cover the
    existing opt-in pattern (agent_id / environment /
    agent_type / attempt_index / is_retry); the new keys
    ride through the same branch and the
    ``test_build_v3_track_payload_*`` suite covers the
    round-trip. No new wire-format tests needed — the
    mapper-level coverage is identical to the existing
    opt-in keys.

Verification locally (origin/master + eb1bb6f on top):

  * pytest tests/test_extractors.py tests/test_crewai_patch.py
    tests/test_runtime.py tests/test_runtime_branches.py
    tests/test_track_batch_retry.py
    tests/test_track_span_context.py
    tests/test_v3_wire_contract.py tests/test_release_polish.py
    — 185 passed, 1 skipped (no regression vs 0.13.10).
  * ruff check src/ — "All checks passed!".
  * mypy src/nullrun — Success: no issues found in 34 source
    files.

No public API change. No SDK_MIN_VERSION bump.

---

v3.24 / 0.13.10 (2026-07-13) — close 5 vendor extractor edge cases
missed in the 0.13.9 audit.

  1. Cohere v2 tool_calls path: the pre-0.13.10 extractor read
     top-level payload["tool_calls"], but Cohere v2 nests the field
     under message.tool_calls (OpenAI shape). Every v2 Cohere call
     shipped with tool_names=[] and the backend's loop detection
     could not see Cohere tool use. Fix walks both v1 (top-level)
     and v2 (message.tool_calls) paths. Same patch adds
     usage.tokens.cached_tokens (cache-hit read was always 0) and
     the UPPERCASE finish_reason vocabulary
     (COMPLETE | MAX_TOKENS | TOOL_CALL) — the _FINISH_REASON_MAP
     already lower-cased both vocabularies; the missing piece was
     the test snapshot.

  2. Mistral num_cached_tokens (flat field on usage, not nested
     under prompt_tokens_details.cached_tokens like OpenAI's). The
     OpenAI extractor only read the nested shape, so Mistral
     customers always saw cache_read_tokens=0 even when the
     inference cache hit. Fix reads the Mistral flat field as a
     fallback inside the same chain. The _openai_extractor host
     map (line 567) already covers Mistral so no host-routing
     change was needed.

  3. Gemini 2.5+ thoughtsTokenCount (reasoning tokens in
     usageMetadata) — was hard-coded to 0, so thinking-mode Gemini
     calls had no visible reasoning column on the dashboard.
     Surfaced as reasoning_tokens while the total stays at
     totalTokenCount (reasoning tokens are part of
     candidatesTokenCount upstream).

  4. Anthropic 4.5+ output_tokens_details.thinking_tokens
     (extended-thinking mode) — was hard-coded to 0 for the same
     reason. The pre-0.13.10 comment ("reasoning tokens are part
     of output_tokens") was correct for the non-thinking baseline,
     but the thinking-mode field was still readable and was being
     dropped. Now we read the breakdown while keeping the total at
     input+output (Anthropic bills thinking tokens at the output
     rate upstream).

  5. AWS Bedrock finish_reason for the Mistral-on-Bedrock /
     OpenAI-compat and Llama-on-Bedrock adapter shapes. The
     pre-0.13.10 extractor only read top-level stopReason /
     stop_reason (Anthropic + Llama top-level). Mistral's
     OpenAI-compat shape puts the field under
     choices[0].finish_reason and was always None. The
     matched_shape discriminator (already tracked in the
     tool-detection block) tells us which body to read from and
     the new branch picks choices[0].finish_reason when
     matched_shape == 'openai_choices'.

The same audit identified the following as should-fix but
deferred to a follow-up PR (none is a billing gap; all are
visibility / observability gaps):

  - Anthropic cache_creation.ephemeral_{1h,5m}_input_tokens
    TTL breakdown (different billing rates; Bedrock does not
    yet expose the breakdown as of 2026-Q3).
  - Anthropic server_tool_use.{web_search_requests,
    web_fetch_requests} — server-side tool invocations not
    visible to loop detection.
  - Gemini multimodal *TokensDetails[] (TEXT vs IMAGE vs
    AUDIO) — image-heavy calls mask the real cost driver.
  - Cohere billed_units.{search_units, classifications} for
    RAG / classify workloads.
  - Cohere reasoning models (command-a-reasoning-*).
  - Bedrock Converse API (separate envelope from InvokeModel).

Wire format: unchanged. Backends on 1.0.0 keep working
unchanged. Pinning unchanged: SDK_MIN_VERSION_FOR_V3 =
"0.12.0". Recommended upgrade path: 0.13.9 -> 0.13.10.

Tests (8 new in tests/test_extractors.py):

  - test_cohere_v2_message_tool_calls_path — v2 nested
    message.tool_calls returns the right tool_names.
  - test_cohere_v2_cached_tokens — tokens.cached_tokens
    surfaces as cache_read_tokens.
  - test_cohere_v1_top_level_tool_calls_fallback — v1
    callers (legacy top-level tool_calls) keep working.
  - test_openai_mistral_num_cached_tokens — Mistral
    usage.num_cached_tokens fallback in the OpenAI extractor.
  - test_gemini_2_5_thinking_tokens — thoughtsTokenCount
    surfaces as reasoning_tokens while the total stays at
    totalTokenCount.
  - test_anthropic_extended_thinking_tokens —
    output_tokens_details.thinking_tokens surfaces
    alongside cache_read_input_tokens /
    cache_creation_input_tokens already extracted.
  - test_bedrock_mistral_finish_reason_via_choices —
    Mistral-on-Bedrock OpenAI-compat finish_reason is now
    captured.
  - test_bedrock_llama_finish_reason_via_top_level —
    Llama-on-Bedrock stop_reason snake_case is captured
    (already worked, but had no test snapshot before).

Verification locally (origin/master + this commit on top):

  * pytest tests/test_extractors.py tests/test_crewai_patch.py
    tests/test_runtime.py tests/test_runtime_branches.py
    tests/test_track_batch_retry.py
    tests/test_track_span_context.py
    tests/test_v3_wire_contract.py tests/test_release_polish.py
    — 185 passed, 1 skipped (8 new tests net-new from this
    commit; no regression on the 177 tests that were green
    on master).
  * ruff check src/ — "All checks passed!".
  * mypy src/ — 11 pre-existing errors (langgraph overload
    mismatches at lines 1818, 1821, 1827; same count as
    origin/master). No new mypy findings from this release.

No public API change. No SDK_MIN_VERSION bump.

---

v3.23 / 0.13.9 (2026-07-13) — crewai 1.15 compatibility + gate_cache
re-capture.

  1. crewai 1.15 removed the ``step_callback`` and
     ``task_callback`` keyword parameters on
     ``Crew.kickoff()``. The pre-0.13.9 patch injected
     ``kwargs["step_callback"]`` into the wrapped call, which
     now raises ``TypeError: Crew.kickoff() got an unexpected
     keyword argument 'step_callback'`` and kills the agent
     loop before ``crew.usage_metrics`` is read.

     0.13.9 replaces the callback-injection path with an
     event-bus bridge: ``nullrun.instrumentation.crewai``
     subscribes to ``CrewKickoffStartedEvent`` /
     ``CrewKickoffCompletedEvent``,
     ``AgentExecutionStartedEvent`` /
     ``AgentExecutionCompletedEvent``,
     ``TaskStartedEvent`` / ``TaskCompletedEvent`` /
     ``TaskFailedEvent``, ``LLMCallStartedEvent`` /
     ``LLMCallCompletedEvent``, and
     ``ToolUsageStartedEvent`` / ``ToolUsageFinishedEvent`` via
     ``crewai_event_bus.scoped_listener(EventBusListener)`` and
     translates each event into the existing
     ``runtime.track_event`` shape (``span_start`` /
     ``span_end`` per kickoff / agent / task / llm / tool).
     Token totals still come from
     ``crew.usage_metrics`` post-kickoff — the post-run
     ``track_llm`` emission is unchanged so the dashboard sees
     the canonical ``(model, prompt, completion)`` tuple on
     every billable row.

     When ``crewai.events`` is not importable (pre-1.15 crewai
     or a stripped-down third-party build) the post-run
     ``usage_metrics`` wrap is still installed and the patch
     returns ``True`` so callers that gate on
     ``\"did nullrun.init register a crewai bridge\"`` keep
     getting a positive answer; only the per-event span
     bridge is a no-op.

  2. ``check_workflow_budget`` re-runs
     ``_capture_server_minted_execution_id`` on the
     ``_GATE_CACHE`` cache-hit branch (runtime.py:1486).
     Pre-0.13.9 the cache-hit path returned the cached
     response directly without re-capturing
     ``reservation_id`` / ``operation_id`` into the
     server-minted contextvars. Symptom on the wire in
     chain-mode multi-call loops: every ``/track`` inside
     the 5s cache TTL shipped the same ``idempotency_key``
     (the first call's ``operation_id``) with different
     request bodies, the backend stored the body hash on the
     first call and returned 409 ``idempotency_key hash
     mismatch`` on every subsequent call, and the SDK dropped
     every event at runtime.py:2649 (zero rows reaching
     Postgres). Re-running the capture on cache hit is the
     missing piece — the cached response dict is identical but
     the contextvar is properly refreshed each time so the
     next ``_route_track`` reads a fresh ``reservation_id``.

     Note: this fixes the per-call contract for the v3
     /track single-event path. Chain-mode loops that re-use
     the *same* chain_id across many gate calls still rely on
     the cache collapsing to one roundtrip, which is the
     intentional design (CLAUDE.md §18 BUG #5 — gate_cache
     debounce). Operators who need a fresh ``/gate`` call on
     every ``@protect`` invocation can opt out via
     ``NULLRUN_GATE_CACHE_DISABLE=1`` (env var, no code
     change).

Wire format: unchanged. Backends on 1.0.0 keep working
unchanged. Pinning unchanged: SDK_MIN_VERSION_FOR_V3 =
"0.12.0". Recommended upgrade path: 0.13.8 -> 0.13.9.

Tests:
  * tests/test_crewai_patch.py — 15 / 15 passed (regression
    suite covers the legacy step_callback kwargs injection,
    the new event-bus fallback when ``crewai.events`` is
    unavailable, and the post-run ``usage_metrics`` reader).
  * tests/test_runtime.py + test_runtime_branches.py +
    test_track_batch_retry.py + test_track_span_context.py +
    test_v3_wire_contract.py — 142 passed, 1 skipped.
  * Real-script smoke on crewai 1.15.2 —
      ``examples/crewai_basic.py`` prints "The capital of
      France is Paris." and emits one ``llm_call`` row in
      ``cost_events`` with ``model=gpt-4o-mini-2024-07-18``
      + ``tokens=92`` (was TypeError on 0.13.8).

  ----

v3.22 / 0.13.7 (2026-07-12) — wire ``parent_trace_id`` end-to-end on
``/track`` (v3 + legacy batch).

Pre-fix (0.13.6): ``langgraph.py::on_llm_end`` set
``event["parent_trace_id"]`` on the llm_call cost event when an
LLM call sat inside a chain / agent, but two leaks dropped the
field on the wire:

  1. ``runtime._enrich_event`` never stamped ``parent_trace_id``
     from the active span contextvar, so non-langgraph integrations
     (crewai, autogen, llama_index, plain httpx transport) emitted
     the field as ``None``.
  2. ``runtime._build_v3_track_payload`` did NOT map
     ``parent_trace_id`` onto the v3 ``/track`` payload, so even
     when the langgraph callback set it, the field dropped at the
     SDK wire boundary.

Result on production (VPS Postgres after deploy 2026-07-11):

  SELECT count(*), count(parent_trace_id)
  FROM cost_events WHERE created_at > '2026-07-11 17:54:00';
  -- 28 | 0

Zero rows carried the parent trace — the backend's unified
SELECT third JOIN arm (``cs.join_kind = 'parent_trace_id'``) never
matched, and the workflow detail "Recent executions" panel showed
empty Model / Tokens / Cost on every orchestration row that owned
an LLM call.

Fix (no public API change, no wire-format change — the field
was always wire-additive; just stop dropping it on the SDK side):

  1. ``runtime._enrich_event``: stamp ``parent_trace_id`` from
     ``get_trace_id()`` contextvar when the caller did NOT set it
     explicitly. The langgraph callback's explicit value wins (no
     second-guessing), preserving the existing contract.

  2. ``runtime._build_v3_track_payload``: map ``parent_trace_id``
     from ``wire_event`` onto the v3 ``/track`` body, mirroring
     the existing ``trace_id`` / ``span_id`` handling.

  3. ``nullrun.context``: add ``set_trace_id`` /
     ``reset_trace_id`` / ``clear_trace_id`` helpers. Tests that
     pin the trace contextvar (mimicking ``@protect`` blocks)
     need a way to set + restore. Matches the existing pattern
     of ``set_/get_/clear_server_minted_execution_id``.

Tests (7 new in ``test_drift_fixes_2026_07_04.py``, all passing):

  - ``test_build_v3_track_payload_includes_parent_trace_id``
  - ``test_build_v3_track_payload_omits_parent_trace_id_when_absent``
  - ``test_enrich_event_stamps_parent_trace_id_from_contextvar``
  - ``test_enrich_event_preserves_caller_set_parent_trace_id``
  - ``test_enrich_event_leaves_parent_trace_id_blank_when_no_contextvar``
  - ``test_enrich_event_omits_empty_string_parent_trace_id``
  - ``test_enrich_event_parent_trace_id_matches_existing_trace_id_field``

Verification locally:

  - ``pytest tests/test_drift_fixes_2026_07_04.py`` — 22/22 passed.
  - ``pytest tests/ -n auto -q`` — 1142 passed, 1 pre-existing flake
    (``test_is_paused_respects_cooldown``, NOT introduced by this
    release).
  - ``ruff check src/`` — All checks passed.
  - ``mypy src/`` — Success: no issues found in 34 source files.

No public API change. No ``SDK_MIN_VERSION`` bump. Backends on
1.0.0 keep working unchanged. Recommended: 0.13.6 → 0.13.7
(patch). Required: backend must have ``cost_events.parent_trace_id``
column from migration 217 (already deployed on prod as of
2026-07-11 12:52 UTC).

---

v3.21 / 0.13.6 (2026-07-11) — multi-agent span attachment (parent_trace_id).

Pre-fix the langgraph callback's on_llm_start/on_llm_end handlers
captured the LLM call under a fresh trace_id whenever no
@protect contextvar was active. The backend's unified SELECT
JOINed on traces.trace_id == cost_events.trace_id and missed
every LLM call inside a chain / multi-agent flow — leaving the
"Recent executions" panel on the workflow detail page with
empty Model / Tokens / Cost on 4 of 5 rows.

SDK changes:
  1. on_llm_start opens a child span off the parent
     LangChain run via NullRunCallback._begin_run (parent_run_id
     or set_span contextvar). The child SpanContext inherits
     trace_id from the parent chain / agent per the existing
     SpanContext invariant — so a multi-span run shares one
     trace_id and the parent_span_id walks the agent tree.
  2. on_llm_end looks that child SpanContext up in
     _active_runs[llm_run_id] and passes trace_id / span_id /
     parent_span_id explicitly into runtime.track_event, so
     _enrich_event forwards them on the wire (alongside
     parent_trace_id, the new field).
  3. runtime._enrich_event now sets parent_trace_id = the
     child span's trace_id (which equals the parent chain's
     trace_id by invariant) on llm_call cost events. The
     backend's cost_events.parent_trace_id column (migration
     217, nullable UUID) persists it; the unified SELECT
     third JOIN arm (`cs.join_kind = 'parent_trace_id'`)
     picks it up and surfaces the LLM model / tokens / cost
     on the orchestration row that owns the call.
  4. The new field is wire-additive: legacy backends that
     don't read it still receive /track payloads and store
     them (the field is dropped on the SQL bind if the column
     is absent, but the migration is shipped in lockstep
     with this SDK release so production environments have
     it). On legacy SDKs that don't set parent_trace_id the
     column stays NULL and the unified SELECT falls through
     to the existing execution_id / trace_id arms (no
     regression).

Tests:
  * tests/test_langgraph_callback.py:
      - test_on_llm_start_then_end_attaches_parent_chain_trace_id
      - test_on_llm_end_outside_active_chain_still_emits_event
      - test_on_llm_end_runtime_failure_is_swallowed
  * 39 pre-existing tests in test_langgraph_callback.py still
    pass; no regression in test_extractors.py,
    test_instrumentation_phase41.py, or the wider suite.

Wire format: backward-compatible. The new field is serde(default)
absent on older SDKs and ignored by older backends. Operators
upgrading from 0.13.5 must upgrade both sides together (SDK to
0.13.6 + backend with migration 217); the SDK alone still works
on 1.0.0 backends (the field is just dropped at the SQL bind).

No SDK_MIN_VERSION bump. Recommended upgrade path: 0.13.5 ->
0.13.6.

---

v3.12 / 0.12.0 (2026-07-03) — server-minted execution_id default ON.

The backend `gate_reserve_v3` now mints a uuidv7 execution_id
internally. This version (`0.12.0`) is the
SDK_MIN_VERSION for the v3 rollout — older SDKs continue to
work because the gate IGNORES the client-supplied execution_id
(it mints its own), but they cannot fully participate in the
v3 /track idempotency contract.

---

v3.12 / 0.12.1 (2026-07-04) — bug-fix: complete the wiring
that 0.12.0 advertised.

Honest history: the v0.12.0 changelog entry above said "the
SDK no longer needs to generate its own execution_id for
/check; it gets the server-minted one back in the response
and propagates it to /track", but the propagation code was
NOT shipped in 0.12.0. The 0.12.0 wire was correct in intent
but the SDK still routed through /track/batch and ignored
`response["reservation_id"]` (see
`docs/sdk-v3-migration-gaps.md` and audit memory
`sdk-v3-migration-gaps`).

0.12.1 ships the four missing pieces:

  1. ``_capture_server_minted_execution_id(response)`` reads
     ``reservation_id`` from the /check response into a
     contextvar ``nullrun.context._server_minted_execution_id_var``.
  2. ``_enrich_event`` stamps the captured id onto /track
     payloads (with a 295s freshness guard so an expired
     reservation never ships a doomed id).
  3. ``_route_track`` dispatches ``llm_call`` events to the
     v3 single-event endpoint ``/api/v1/track`` via
     ``Transport.track_single``, so the backend's
     ``gate_consume_v3`` validates the consume-vs-reserve +
     ε invariant.
  4. ``NULLRUN_V3_TRACK_DISABLE=1`` opt-out for backends still
     on the v1/v2 path.

Pinning: still SDK_MIN_VERSION_FOR_V3 = "0.12.0". Operators
upgrading from < 0.12.0 should jump straight to 0.12.1 — 0.12.0
released with the integrity bug above and was never deployed
in production with the v3 wiring.

---

v3.12 / 0.12.2 (2026-07-04) — bug-fix: fresh execution_id
/check + in-process chain-mode gate cache.

Two related correctness fixes on top of 0.12.1:

  1. ``check_workflow_budget`` now sends a fresh ``uuidv7`` as
     ``execution_id`` on every /check call (instead of reusing
     ``workflow_id``). The v3 ``gate_reserve_v3`` mints its
     own anyway, but a client-side placeholder that collides
     across calls confuses the reservation binding on
     /track when ``track_single`` returns 503
     ``RESERVATION_NOT_FOUND``. The server
     overwrites the field on response, so the freshly-minted
     ``reservation_id`` captured by
     ``_capture_server_minted_execution_id`` still drives
     /track exactly as in 0.12.1.

  2. New in-process gate cache
     (``nullrun.runtime._GATE_CACHE``) serves chain-mode
     @protect calls from a 5s TTL on the same
     ``(workflow_id, chain_id, model)`` triple, collapsing
     100-step agent loops to a single /gate roundtrip. Single-
     shot (Hard mode) callers bypass the cache — the gate
     legitimately flips allow→block between consecutive
     calls there, and a stale "allow" could leak a budget-
     exhausted call. Opt-out via
     ``NULLRUN_GATE_CACHE_DISABLE=1`` for callers that want
     the legacy always-roundtrip behaviour (e.g. for live
     smoke tests per docs/runbooks/budget-blue-green-smoke.sh).

No wire-format change. Pure client-side fix — backends on
1.0.0 keep working unchanged. Pinning unchanged:
SDK_MIN_VERSION_FOR_V3 = "0.12.0". Recommended upgrade
path: 0.12.1 -> 0.12.2.

---

v3.13 / 0.13.0 (2026-07-04) — drift-fixes release: closes the SDK-side
items left over from the docs-vs-code audit captured in
`docs/`.

  1. ``idempotency_key`` wired onto the v3 /track single-event
     payload. New contextvar
     ``nullrun.context._server_minted_idempotency_key_var`` +
     ``get_/set_/reset_/clear_server_minted_idempotency_key``
     ``_capture_server_minted_execution_id`` now also captures
     ``response["operation_id"]`` (which equals the /check
     idempotency_key, runtime.py:1260); ``_enrich_event`` stamps
     the value onto the ``wire_event`` for ``llm_call``
     ``_build_v3_track_payload`` propagates it onto the v3 /track
     body with a contextvar fallback for tests + direct callers.
     Without this, transport-level retry on the same event either
     503'd with ``RESERVATION_NOT_FOUND`` (reservation key DEL'd
     after the first consume per ) or double-billed
     the underlying budget.

  2. Wire ``status_code`` preserved through every decision
     exception class. ``NullRunBlockedException``
     ``NullRunBudgetError``, ``NullRunChainError``
     ``NullRunWorkflowInactiveError``
     ``NullRunConsumeOverbudgetError`` now all accept
     ``status_code: int | None = None``; ``_parse_v3_error_envelope``
     sets it from ``response.status_code`` for every branch —
     402 budget, 403 workflow/chain cross-org, 422
     ``CONSUME_OVERBUDGET``, 503 ``RATE_LIMIT_REDIS_UNAVAILABLE``
     etc. FastAPI exception handlers reading ``exc.status_code``
     previously got ``None`` / 500 for budget blocks (the backend's
     402 was lost in the constructor chain).

  3. The runtime.py module docstring now distinguishes
     SDK-side transport failure (network/5xx/breaker open →
     fail-OPEN on /check) from wire 4xx/5xx that names an
     enforcement failure (``BUDGET_REDIS_UNAVAILABLE`` → 402
     fail-CLOSED; ``RATE_LIMIT_REDIS_UNAVAILABLE`` → 503
     fail-CLOSED). The README had conflated the two with a single
     "fail-OPEN on infra failures" claim.

Tests:
  * ``tests/test_drift_fixes_2026_07_04.py`` — 15 tests (5 idempotency
    8 status_code on every decision exception, 2 fail-CLOSED on
    wire 503 RATE_LIMIT_REDIS_UNAVAILABLE).
  * ``tests/test_v3_wire_contract.py::TestGateCacheRuntimeFlow`` — 3
    runtime-level chain-mode cache tests that close the 0.12.2
    patch-coverage gap (dragged codecov/patch below the 70% floor
    on PR #52). Drives ``NullRunRuntime.check_workflow_budget``
    inside ``with workflow(...) + with chain(...)`` to exercise
    cache_enabled / cache-hit / cache-miss /
    cache-bypass-via-env branches (runtime.py:1287-1310).

Backends on 1.0.0 keep working unchanged. Pinning unchanged:
SDK_MIN_VERSION_FOR_V3 = "0.12.0". Recommended upgrade
path: 0.12.2 -> 0.13.0 (no on-wire breaking change; the SDK
will pick up the new idempotency_key stamping automatically).

---

v3.15 / 0.13.1 (2026-07-04) — drift-fixes release: closes the four
BLOCKER items from the SDK↔backend drift audit that were still active
in 0.13.0.

  1. ``Transport.check_v3`` (drift B1): was POSTing to ``/api/v1/check``
     (removed 2026-06-27 — handler now returns 410 Gone with
     ``replacement: /api/v1/gate``). Now delegates to ``Transport.check``
     which targets ``/api/v1/gate`` and forwards all v3 wire fields
     (``chain_id``, ``chain_op``, ``idempotency_key``, ``stream``).
     ``check `` is the canonical entry point; ``check_v3`` is kept
     as a v3-named alias for callers/tests that already use it.

  2. ``Transport.track_single`` docstring + ``tests/test_v3_wire_contract.py::
     test_track_single_includes_protocol_header`` body (drift B2): the
     docstring described a fictitious wire shape ``{execution_id
     actual_cost_cents, api_key_id, cost_source}``. The real backend
     ``TrackRequestRaw`` is ``{workflow_id, tokens, cost_cents,...}``
     (built by ``runtime._build_v3_track_payload``) — ``execution_id``
     is replaced by ``reservation_id``, and the SDK always emits
     ``cost_cents: 0`` because the backend recomputes the authoritative
     cost from tokens + the org's pricing policy (see
     ``_WIRE_STRIP_FIELDS`` in runtime.py). ``api_key_id`` is derived
     server-side from the request auth, not supplied by the SDK.
     Docstring + test body now match the real contract.

  3. ``Transport.chain_end`` (drift B3): was POSTing to
     ``/api/v1/chain/end`` — that endpoint was never registered on
     the backend (``backend/src/proxy/http/routes.rs`` has zero
     matches). Now POSTs to ``/api/v1/gate`` with ``chain_op: "end"``
     (matches the documented backend contract from
     ``backend/src/proxy/http/cancel.rs:39``'s own comment).

  4. ``Transport.approximate_budget`` (drift M3): was appending
     ``?organization_id=<id>`` to the URL. The backend's
     ``approximate_budget_handler`` (``backend/src/proxy/http/
     budget.rs:130-145``) resolves the org from the X-API-Key /
     Authorization header — it does NOT accept a query parameter.
     The method now calls the bare URL. The ``organization_id``
     argument is retained as an accepted-but-unused parameter for
     backward compatibility with any external caller that still
     passes it (silently no-ops).

Tests touched (in ``tests/test_v3_wire_contract.py``):
  * ``test_check_v3_includes_protocol_header`` — re-mocked against
    /api/v1/gate (was /api/v1/check).
  * ``test_check_v3_accepts_chain_context`` — re-mocked against
    /api/v1/gate (was /api/v1/check).
  * ``test_chain_end_includes_protocol_header`` — re-mocked against
    /api/v1/gate (was /api/v1/chain/end); added chain_op=end check.
  * ``test_chain_end_sends_chain_id_in_body`` — re-mocked against
    /api/v1/gate (was /api/v1/chain/end); added chain_op=end check.
  * ``test_track_single_includes_protocol_header`` — body now matches
    the real wire shape (reservation_id + workflow_id + tokens +
    cost_cents:0 + cost_source:"provisional").

1037 lib tests pass (no regression). Recommended upgrade path:
0.13.0 -> 0.13.1. No SDK_MIN_VERSION bump — wire format is the same
from the caller's perspective; only the URLs and docstrings changed.

---

v3.15 / 0.13.2 (2026-07-06) — typing-debt sweep + singleton/registry
split. No on-wire change; backends on 1.0.0 keep working unchanged.

  1. ``pyproject.toml`` mypy config rewritten from a single
     blanket ``ignore_errors = true`` (12 files / 102 errors swallowed)
     to per-file ``[[tool.mypy.overrides]]`` blocks — every legacy
     module now declares the EXACT error codes it carries, so CI
     breaks the moment a NEW code appears in that module rather
     than the previous "everything passes" status. ``strict = true``
     is enabled on the 14 modules already clean enough to keep it;
     modules still carrying debt opt in via targeted
     ``disable_error_code`` lists. Per the comment block at the
     top of the overrides section: when a file's count drops to 0,
     remove its override row — the table and the debt tracker stay
     in lockstep.

  2. Singleton state split out of ``runtime.py`` into two new
     internal modules:

       * ``nullrun._singleton`` — ``NullRunRuntimeMeta`` descriptor
         backing the ``_instance`` class attribute (the one and
         only canonical instance slot). Module-level ``_runtime``
         PEP 562 ``__getattr__`` proxies in runtime.py /
         decorators.py route reads through here so
         ``import nullrun; nullrun.runtime`` and
         ``from nullrun.runtime import _runtime`` both resolve to
         the same instance without the legacy
         ``_instance = runtime`` assignment that broke whenever
         the metaclass was bypassed (e.g. by ``copy.deepcopy``
         or by tests that constructed ``NullRunRuntime`` directly
         without going through ``__init__``).

       * ``nullrun._registry`` — the per-process registry of
         runtime capabilities (chain-mode gate cache, LRU
         fingerprints, websocket handles). Previously inlined
         as module globals in ``runtime.py``; now centralised
         so the orchestrator module stays under the strict-mypy
         umbrella and external test code can swap or inspect the
         registry without monkeypatching the orchestrator.

  3. ``NullRunRuntime._instance = runtime`` backwards-compat line
     retained at the bottom of ``NullRunRuntime.__init__`` so
     external callers that read ``NullRunRuntime._instance``
     directly (and there are a handful in the integration tests
     shipped by partners) keep working — the new metaclass
     descriptor makes the assignment a no-op for the singleton
     case but is still semantically a write so legacy reflection
     code does not crash.

  4. ``ruff`` ignore list dropped ``F821`` (undefined name) — the
     one site was a typo fixed by the previous ``fix typos``
     commit on this branch. The remaining five (S110 / E501 /
     F841 / E402 / F401) are pre-existing and explicitly tracked
     in the pyproject comment block for a future cleanup PR.

  5. ``tests/test_registry.py`` (new, 12 tests) — covers the
     registry / singleton contract end-to-end:
     ``NullRunRuntimeMeta`` raises on second ``__init__``,
     ``reset_for_tests`` clears the registry without touching
     the class descriptor, ``_capture_server_minted_*`` context
     helpers round-trip through the new module, and the legacy
     ``_instance`` read path still returns the live singleton
     after the split.

Tests:
  * ``tests/test_registry.py`` — 12 tests for the new modules.
  * Existing suite untouched: 1037 lib tests still pass.

Backends on 1.0.0 keep working unchanged. Pinning unchanged:
SDK_MIN_VERSION_FOR_V3 = "0.12.0". Recommended upgrade path:
0.13.1 -> 0.13.2 (typing-only change for end users; visible
delta is the per-file mypy table in pyproject.toml).

v3.16 / 0.13.4 (2026-07-08) -- bug-fix: complete the LangChain
usage-extraction elif-chain.

Pre-fix extract_usage_from_response walked the 4 source branches
if-hasattr-usage_metadata ... elif-hasattr-generations ...
elif-hasattr-usage ... elif-hasattr-response_metadata. A LangChain
AIMessage can carry token info on multiple attributes at once.
When the first branch's hasattr returned True but the value was
empty or 0/0/0 (streaming init state, some provider wrappers),
every subsequent elif was skipped and the SDK shipped tokens=0
to the backend -- making the LLM call invisible on the dashboard.

Switched all 4 source branches to plain if so each one attempts
its read; later branches naturally overwrite the zero default when
the earlier branch value is empty. New regression test
test_extract_usage_metadata_zero_response_metadata_real.

39 tests in test_langgraph_callback.py still pass; no
regression in test_extractors.py or
test_instrumentation_phase41.py. Wire format is unchanged.

Recommended upgrade path: 0.13.3 -> 0.13.4. No SDK_MIN_VERSION
bump; backends on 1.0.0 keep working unchanged.

---

v3.16 / 0.13.5 (2026-07-08) — perf release: cancel the Transport
flush-thread sleep so ``runtime.shutdown()`` returns in ms, not
seconds. Plus CI hygiene so the freed time actually surfaces as
faster CI.

  1. ``Transport._flush_loop`` (transport.py:816) swapped its bare
     ``time.sleep(self.config.flush_interval)`` for
     ``self._stop_event.wait(timeout=...)``. The previous loop was
     uncancellable — any caller of ``runtime.shutdown()`` while the
     thread was mid-sleep blocked on ``thread.join()`` for the full
     default 5s ``flush_interval`` before teardown could proceed.
     With 1222 tests in the suite and many paths calling
     ``shutdown()`` (or its fixture teardowns), that multiplied into
     ~10-15 minutes of pure teardown wall-clock per Python in the
     matrix. New ``threading.Event`` is set by ``stop()`` before
     ``join()`` and cleared by ``start()`` so a restart-after-stop
     is clean. Pin contract: ``tests/test_transport.py::
     test_stop_interrupts_flush_sleep`` uses a 30s ``flush_interval``
     and asserts ``stop() < 5s``; pre-fix this took 30s, post-fix
     ~0.3s.

  2. CI workflow cleanup (.github/workflows/ci.yml +
     publish.yml + publish-test.yml):

       * ``setup-python`` action now declares ``cache: pip`` with
         ``cache-dependency-path: pyproject.toml`` so warm caches
         skip the ~60-90s cold ``pip install -e .[dev]`` per matrix
         leg.
       * ``strategy.fail-fast: true`` on the test matrix so a red
         run doesn't burn the remaining Python legs once the first
         one fails.
       * ``pip install "pytest-xdist>=3.6"`` + ``pytest -n auto`` so
         the suite runs across all runner cores. ``xdist`` is also
         added to ``[project.optional-dependencies.dev]`` so local
         ``pip install -e .[dev]`` brings it in by default.
       * ``coverage`` job also gets ``-n auto`` (single Python leg,
         3.12, is unchanged).

  3. ``pyproject.toml``: dropped the global ``-q`` from
     ``addopts`` so CI logs surface the full ``PASSED`` line per
     test. ``--tb=short`` keeps tracebacks compact. ``-n auto``
     stays in the workflow (not in ``addopts``) so a developer
     running ``pytest tests/test_x.py`` locally still gets a single
     process — the worker pool is only worth it on the full
     suite.

No public API change. The default ``FlushConfig`` is unchanged
(5s ``flush_interval``, 50 ``batch_size``); production flush cadence
is identical. The fix only shortens the worst-case shutdown latency.
No SDK_MIN_VERSION bump. Backends on 1.0.0 keep working unchanged.
Recommended upgrade path: 0.13.4 -> 0.13.5.

"""

__version__ = "0.14.6"
__platform_version__ = "1.0.0"