feat(manual): expose execution_type and manual execution fields

[snevesbarros]

Keeps this client in step with Angles 3.0, which adds manual test case management. Builds and executions produced by a manual test run are tagged executionType: "manual"; everything this client reports stays "automated".

This is a reporting client for automated test frameworks, so it gets no manual test management surface — only the ability to read the new fields back. The full manual API surface lives in angles-javascript-client, which backs angles-ui.

Changes

• ExecutionTypes str enum, following the existing GroupingPeriods style. Exported from both angles_python_client and angles_python_client.models.
• Build.executionType
• Execution — executionType, plus the manual-only manualTestCase, manualTestCaseVersion, versionNumber and executedBy
• Step.attachments, alongside the existing screenshot
• Period.executionTypeBreakdown and PhaseMetrics.executionType — added to the phase metrics response in 3.0
• Optional execution_type filter on get_builds, get_builds_with_filters, get_builds_with_date_filters and get_phase_metrics

The two metrics response fields weren't in the original plan, but 3.0 added them to the response and these dataclasses exist to document the wire shape — omitting them would leave the documented shape wrong.

These fields are read-only, by design

CreateBuild and CreateExecution deliberately do not carry executionType. It is what distinguishes a manual run from an automated one, and a reporting client setting it to "manual" would put a build on the dashboard that no manual test run exists to explain. It stays server-assigned — POST /build from this client gets the schema default.

Verified rather than assumed: neither dataclass has the field.

Backwards compatibility

execution_type is a trailing keyword argument everywhere, so existing positional calls are unaffected. It accepts an ExecutionTypes member or a plain string, and is omitted from the query string entirely when unset — so omitting it returns both types, exactly as before.

Version

Moved to 3.0.0 so the client's major version tracks the API's. Applied with bump2version so pyproject.toml and .bumpversion.cfg stay in step — the release workflow's post-release bump reads the latter, and a mismatch would break it. The workflow publishes the pyproject version verbatim, so this releases as 3.0.0.

Verification

• Existing suite: 15 passed
• 25 checks pass, including that omitting the filter emits no query parameter, that legacy positional calls still work, and the create-payload checks above
• python -m build produces angles_python_client-3.0.0-py3-none-any.whl

🤖 Generated with Claude Code