chore(deps): docker: bump the all-docker group across 1 directory with 2 updates

[dependabot]

Warning

Cooldown could not be applied because no publication date was available from the registry.

Bumps the all-docker group with 2 updates in the /agent directory: jdxcode/mise and python.

Updates jdxcode/mise from df5adf5 to d549958

Updates python from 3.13-slim to 3.14-slim

[scottschreckengaust]

Verdict: Comment (approve-able after a conscious call on the 3.14 runtime jump)

Dependabot Docker-group bump of agent/Dockerfile with two updates: jdxcode/mise digest (df5adf5 -> d549958) and the runtime base image python:3.13-slim -> python:3.14-slim. The mise digest bump is routine and low-risk. The Python bump is a feature-release jump of the production runtime interpreter and deserves a deliberate decision rather than an auto-merge, because it moves the shipped interpreter a full release ahead of every quality gate that validates the code.

Governance

Dependabot PR - no backing issue is required by design (expected, not a blocker). Branch name is the standard dependabot/docker/... pattern (de-facto waived). Transitive-pin sync (root resolutions -> integrations/jira-forge-app overrides, AGENTS.md #712) is not applicable - this is a Dockerfile base-image change, not an npm resolutions bump. agent/uv.lock is untouched and requires-python = ">=3.13" still permits 3.14, so lockfile integrity is intact.

Vision alignment

Keeping base images current is consistent with "bounded blast radius" and the Dockerfile's own CVE-patching rationale (it rebuilds to pick up Debian point-release fixes). The concern is the reliability tenet: shipping the agent runtime on an interpreter that no CI job exercises works against "keep the control plane reliable."

Non-blocking, but notable

1. Runtime interpreter (3.14) now diverges from every dev/CI/quality gate (3.13). After this bump the deployed container runs on Python 3.14 (the base image supplies /usr/local/bin/python; the Dockerfile builds the venv via uv sync --frozen and does not copy agent/mise.toml or a .python-version, so uv selects the system 3.14), while:

   • agent/mise.toml:4 pins python = "3.13"
   • agent/pyproject.toml:97 sets ruff target-version = "py313"
   • agent/pyproject.toml:184 sets ty python-version = "3.13"
   • agent/pyproject.toml:180 explicitly notes asyncio.get_event_loop_policy() is deprecated in 3.14+ (awareness that 3.14 changes behavior; no direct first-party use in agent/src, but it lives in the async stack this runtime depends on).
     Recommendation: move these together - bump mise.toml, ruff target-version, and ty python-version to 3.14 in the same change so lint/type-check/tests actually validate the interpreter that ships; or hold the python line at 3.13-slim and let only the mise digest bump merge.

2. The PR build check does not build the container image, so green CI does not validate 3.14. .github/workflows/build.yml runs mise run install + mise run build on the runner using mise-pinned Python 3.13; the agent image (with the python:3.14-slim base) is only built as a CDK Docker asset at deploy time. That means cp314 wheel availability for the native/compiled pins (cedarpy==4.8.4, plus transitive pydantic-core, aws-opentelemetry-distro, bedrock-agentcore, mcp) and any 3.14 behavioral change are unverified by the checks on this PR and would first surface at deploy-time uv sync --frozen. This image-build-coverage gap is pre-existing (not introduced here), but it is exactly why the 3.14 jump should not ride in silently. Suggest a local/deploy smoke build against 3.14 before merge.

3. Splitting the group would de-risk. The mise digest bump is safe to take now; the interpreter feature-bump should be a separate, deliberate change coupled with item 1.

Nits

• agent/Dockerfile:44 (unchanged context, cannot anchor inline): the apt-upgrade comment still cites python:3.13-slim as the tag that "rides" CVEs until upstream rebuilds. After this bump the base is 3.14-slim - update the illustrative tag to avoid drift.
• Digest provenance (that d549958... / cad9a2c... are the genuine multi-arch indices for the stated tags, incl. linux/arm64) could not be verified from this review sandbox; the Dockerfile's own "verify with docker buildx imagetools inspect" note should be honored before merge.

Documentation

No docs impact for a base-image digest/tag bump. Starlight mirror unaffected. If item 1 is taken (bumping the 3.13 pins to 3.14), no additional docs are required.

Tests & CI

All required checks on head e9de457 are green (build (agentcore), Validate PR title, Secrets/deps/workflow scan, dead-code advisory; CodeQL/auto-approve skipped). No CDK constructs/stacks/handlers or CFN resource types changed, so bootstrap policy / synth-coverage review is not applicable. No unit tests are expected for a base-image bump; the relevant coverage gap is the un-built image (item 2), not a missing */test/ addition.

Review agents run

This execution context cannot spawn the nested pr-review-toolkit agents, so I performed the equivalent analysis by hand and state that limitation explicitly:

• code-reviewer (hand-equivalent): ran - Dockerfile-only diff; findings above.
• security-review (hand-equivalent): ran - base-image bump has a CVE-patching dimension; no IAM/Cedar/network/secrets/input-gateway surface changed. Digest provenance unverifiable from sandbox (nit).
• silent-failure-hunter: omitted - no error-handling/control-flow code in the diff.
• type-design-analyzer: omitted - no types added/changed.
• comment-analyzer (hand-equivalent): ran - flagged the now-stale 3.13-slim reference at Dockerfile:44.
• pr-test-analyzer (hand-equivalent): ran - no tests changed; the substantive coverage concern is the image not being built in PR CI (item 2), not a missing unit test.

Human heuristics

• Proportionality: concern - a routine digest bump and a runtime feature-release jump are grouped into one auto-PR; the latter is disproportionate to auto-merge without pin alignment (agent/Dockerfile:29).
• Coherence: concern - same concept ("the Python we support") now expressed as 3.14 in the runtime but 3.13 across mise.toml:4, ruff (pyproject:97), and ty (pyproject:184).
• Clarity: pass, with the stale-comment nit at agent/Dockerfile:44.
• Appropriateness: concern - the shipped interpreter is not exercised by any PR check (built only at deploy), so "verified against real behavior" is not yet satisfied for 3.14.

[scottschreckengaust]

Runtime interpreter feature-jump 3.13 -> 3.14. The container builds its venv via uv sync --frozen off this base image (no agent/mise.toml / .python-version is copied in), so the deployed agent will run on Python 3.14 while every quality gate still validates 3.13: agent/mise.toml:4 (python = "3.13"), ruff target-version = "py313" (pyproject.toml:97), ty python-version = "3.13" (pyproject.toml:184), and pyproject.toml:180 explicitly notes 3.14+ deprecation behavior. The PR build check runs on mise-pinned 3.13 and does not build this image, so 3.14 (incl. cp314 wheels for cedarpy==4.8.4 and other native pins) is unvalidated by CI. Recommend either bumping the 3.13 pins to 3.14 in the same PR so lint/type/tests match the shipped interpreter, or holding this line at 3.13-slim and merging only the mise digest bump.

[scottschreckengaust]

mise digest bump (df5adf5 -> d549958) - routine and low-risk. Please confirm the new digest is the genuine multi-arch index for jdxcode/mise:latest (incl. linux/arm64) via docker buildx imagetools inspect, per this file's own bump note; I could not verify registry provenance from the review sandbox.