v0.4.0

Added

• ⚠ New migration 0002_snapshot_state — run migrate when upgrading.
  StoredSnapshot gains a state column mirroring the harness's SnapshotState
  (complete / interrupted, defaulting to complete, so existing rows keep
  today's behaviour).

  A complete snapshot sits at a boundary where every tool call has a matching
  return, so resuming from it is always safe. An interrupted one is a rescue
  point captured mid-tool-cycle — pending calls may be re-executed or closed out
  with synthesized returns — so latest_snapshot() now skips interrupted rows
  unless asked for them. The state has to be stored rather than inferred:
  by the time a resume is attempted, the run that produced the row is gone.

  When several snapshots exist, the state filter applies after ordering, so
  the newest complete row wins even when newer interrupted rows sit above it
  — the same walk-back-from-newest the harness reference stores do.

Changed

• [harness] now requires pydantic-ai-harness>=0.12,<0.13 (was >=0.7,<0.8).
  The ceiling had gone five minors stale, which on a 0.x library is where breakage
  accumulates — and it did. It also gated
  pydantic_ai_harness.skills,
  which does not exist below 0.11 and is the prerequisite for adopting agent skills.
• ⚠ DefaultStepStore.latest_snapshot() gained an include_interrupted
  keyword, matching the harness's StepStore protocol. Harness's own
  continue_run() passes it, so before this the resume path raised
  TypeError: latest_snapshot() got an unexpected keyword argument. Any custom
  StepStore implementation must add the same parameter.
• Raise the drf-chain ceilings: [drf-mcp] → djangorestframework-mcp-server>=0.17,<0.18
  (was >=0.15,<0.16) and [spec-tools] → djangorestframework-pydantic-ai>=0.9,<0.10
  (was >=0.8,<0.9). The MCP ceiling had gone stale a wave earlier — drf-mcp
  0.16.0 (MCP Apps) was already excluded — so two upstream releases were
  unreachable from here rather than one. No adaptation was needed, which the
  three relevant upstream changes explain:
  • MCP Apps (drf-mcp 0.16.0) adds ui:// resources and _meta.ui links on
    tool definitions. The bridge reads name / description / inputSchema /
    outputSchema / annotations off tools/list and ignores _meta, so the
    addition is inert here. The resource-encoding fix in the same release (non-JSON
    resource bodies no longer come back as quoted JSON string literals) touches
    the resource surface, which this bridge does not use — it calls tools only.
  • The shared UrlKwarg / QueryParam (drf-mcp 0.17.0, PAI 0.9.0) are
    re-exported from djangorestframework-services rather than defined locally,
    behind permanently preserved import paths. Neither is imported here. PAI's
    switch from ValueError to ImproperlyConfigured for a bad channel
    declaration is likewise unreachable: SpecCapability is constructed with a
    spec mapping and no channel registrations.
  • InputRequired enforcement (drf-services 0.28) makes a missing
    marked-required input raise ServiceValidationError at dispatch. Over the
    MCP bridge that already arrives as an isError result with
    type == "validation_error", which call_tool maps to ModelRetry — so a
    spec adopting the marker gets a model-correctable failure through this path
    with no change here.