v0.2.0

Added

• Spec composition accepts a spec registry, not just a mapping.
  build_spec_capability(specs, request, …) now takes either a
  name -> spec mapping or a spec registry — drf-services 0.27's
  SpecRegistry, the one declaration site for a project exposing the same specs
  over more than one transport. New resolve_spec_mapping() helper and a
  SpecSource Protocol.
  • Matched structurally, not imported. SpecSource declares only
    specs() -> dict, so this substrate still names no drf-services type and
    still depends on pydantic-ai-slim alone — drf-services arrives only with
    the optional [spec-tools] extra. Naming SpecRegistry in a signature
    would either force the dependency on every install (including projects whose
    tools are plain @tool functions) or bury the type behind a lazy import
    where it cannot appear in a signature at all. drf-services duck-types
    SelectorSpec.filter_set for the same reason.
  • resolve_spec_mapping() is public on purpose. A transport needs the
    same normalisation before the builder runs: iterating a registry yields
    RegisteredSpec records, not names, so a transport reserving tool names by
    iterating the raw argument would fill its collision-detection set with
    dataclasses and silently stop detecting duplicates between the @tool
    registry, the drf-mcp bridge and the spec tools.

Changed

• [spec-tools] now requires djangorestframework-pydantic-ai>=0.8,<0.9
  (was >=0.5,<0.6) — registry support landed in PAI 0.8.
• [drf-mcp] now requires djangorestframework-mcp-server>=0.15,<0.16
  (was >=0.12,<0.13). This is not optional housekeeping: drf-mcp 0.12 caps
  drf-services at <0.26 while PAI 0.8 requires >=0.27, so moving only
  [spec-tools] makes the two extras mutually uninstallable. They have to
  advance together.

Documentation

• A real documentation site. The package shipped in 0.1.0 with 36 exported
  symbols, a one-paragraph docs/index.md and a nav containing only "Home" — no
  reference at all. It now has five narrative pages (Concepts, Tools, Storage,
  Policy, Integrations) and a five-page autodoc reference covering the whole
  public surface, plus a README that says what the package does rather than only
  what it is. Highlights the things the source knows but nothing surfaced:
  capabilities compose order-independently; category is advisory while
  destructive drives the gate; the x-* schema keys reach the client while
  DESTRUCTIVE_METADATA_KEY is read server-side; stores key on
  (owner_id, thread_id), so two transports sharing one store share a user's
  thread list unless wrapped in ScopedConversationStore.
• Corrected a claim that this package declares a StepStore protocol. It
  does not — DefaultStepStore structurally satisfies pydantic-ai-harness's
  protocol, which is upstream's. The repo conventions asserted otherwise in two
  places.

Fixed

• The spec-conventions test asserted behaviour that changed in PAI 0.6.0.
  SpecCapability.get_instructions() has returned None since the conventions
  moved onto SpecToolset.get_instructions() (so they reach the model whether a
  toolset is attached directly or wrapped, and are collected exactly once). The
  stale [spec-tools] ceiling pinned this package below 0.6, so the assertion
  kept passing against an API two minors old; raising the pin surfaced it. The
  test now reads the instructions off the toolset, and
  build_spec_capability's module docstring no longer claims the capability
  emits them.