chore(release): v1.5.0

Minor bump covering the two features that have accumulated on main since v1.4.0, both additive with no breaking SDK surface.

`relationships(type, source)` on entities (#54) exposes the two keys the API added to each entity relationship entry, and carries a consumer-facing note worth reading: the `relation` value vocabulary changed upstream, so application code branching on `relation` should match on `type` instead. No SDK code change is required for that — `relation` was and remains a `str`.

`PaginatedResponse.meta` (#55) surfaces the API's agency-filter diagnostics, which the SDK previously discarded because it built the response envelope key-by-key. Adds `unresolved_agency_tokens`, `resolved_agencies`, and `agency_warnings`. The second of those is the one that matters for a fuzzy match landing on the wrong organization — nothing is dropped in that case, so a dropped-token check cannot see it.

Version bumped in pyproject.toml, tango/__init__.py and uv.lock; [Unreleased] promoted to [1.5.0] - 2026-08-04.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: vdavez

CHANGELOG.md

@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.5.0] - 2026-08-04
+
 ### Added
 - **`relationships(type, source)` on entities.** Tango API 4.20.0 added two keys to each entry in the entity `relationships` expand: `type`, the stable relationship-type code (`prime_sub`, `parent_subsidiary`, `ultimate_parent`, `predecessor`), and `source`, where the tie came from (`sam`, `subawards`). Both are shape-selectable, so `shape="uei,relationships(type,source,uei)"` now resolves against the SDK's schema. Re-vendored the contract and regenerated the shape overlay; the coverage gate reports 0 gaps.
 - `PaginatedResponse.meta` now carries the response-level `meta` block the API returns, with three accessors over it: `unresolved_agency_tokens` (agency tokens that matched nothing, per filter), `resolved_agencies` (the organization each token *did* match), and `agency_warnings` (the API's human-readable notes). Agency values resolve fuzzily, so a token can match an organization the caller did not intend and quietly scope the query to that subtree — and a token that resolves to nothing was previously dropped with no signal at all. Both cases were indistinguishable from "no such records exist". The API now reports both; until now the SDK read the envelope key-by-key and dropped `meta` on the floor, so SDK users were the one group that could not see it. `resolved_agencies` is the accessor that matters for the wrong-organization case: nothing is dropped there, so an unresolved-token check cannot detect it. All accessors return empty rather than raising when `meta` is absent (most responses) or malformed.

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "tango-python"
-version = "1.4.0"
+version = "1.5.0"
 description = "Python SDK for the Tango API"
 readme = "README.md"
 requires-python = ">=3.12"

tango/__init__.py

@@ -50,7 +50,7 @@
 )
 from .webhooks.receiver import Delivery, WebhookReceiver
 
-__version__ = "1.4.0"
+__version__ = "1.5.0"
 __all__ = [
     "TangoClient",
     "TangoAPIError",