fix(cli): only claim uipath new scaffolds for the matching framework

[vldcmp-uipath]

Draft until UiPath/uipath-python#1886 is approved and uipath 2.14.15 is published. The middlewares import uipath._cli.models.project_types / uipath._cli.models.agent_frameworks and call AgentFramework.claims_scaffold(), which only exist from 2.14.15. For dev-build validation each package temporarily pins uipath==2.14.15.dev1018867616 (the dev build of #1886) from the testpypi index. Before marking ready for review: restore "uipath>=2.14.15, <2.15.0", drop the [tool.uv.sources] testpypi entry for uipath, and re-run uv lock in each package.

Problem

Every integration's new middleware returned should_continue=False unconditionally, so installing any of them made the base uipath new function scaffold unreachable — uipath new <name> always produced that framework's agent project. Fixes the integrations' half of UiPath/uipath-python#1543; the companion PRs are #1886 (base CLI) and uipath-langchain-python#1069.

Changes

• All six middlewares take the project_type / agent_framework that uipath new forwards and defer (should_continue=True) unless the scaffold is theirs, via the shared gate added in #1886:

  if not AgentFramework.PYDANTIC_AI.claims_scaffold(project_type, agent_framework):
      return MiddlewareResult(should_continue=True)

  --type auto (the default) is claimed by whichever integration is installed — today's behaviour — --type agent only by the framework it names, and --type function by none. The rule is identical for every framework, so it lives in the base package and each integration just names itself.

• Dropped a duplicated generate_pyproject call in the agent framework, Google ADK, LlamaIndex and OpenAI Agents scaffolds, which wrote pyproject.toml twice on every run. Generation order is now the same everywhere (script, then pyproject).

• uipath floor moves to the release that forwards these arguments, with uipath-runtime following to >=0.13.1, <0.14.0 as that release requires; uipath-platform floors align at >=0.2.27.

• Version bumps: uipath-agent-framework 0.1.1, uipath-claude-sdk 0.1.1, uipath-google-adk 0.1.1, uipath-llamaindex 0.6.2, uipath-openai-agents 0.1.2, uipath-pydantic-ai 0.1.2.

Behaviour

Command	Result
uipath new my-fn (or --type auto)	unchanged: the installed integration scaffolds its agent
uipath new my-fn --type function	base function project — the integration now steps aside
uipath new my-agent --type agent	the installed integration's agent (the base CLI resolves the framework first)
uipath new my-agent --type agent --agent-framework pydantic-ai	only uipath-pydantic-ai claims it; the others pass through

Compatibility

An older base CLI calls the middleware with just the name; the defaults (project_type=ProjectType.AUTO) still claim the scaffold, so behaviour there is unchanged. The enums subclass str, so a caller passing plain strings gates identically — covered by a test in every package.

Testing

• Full suites green against the dev build in all six packages: 171 / 231 / 130 / 171 / 73 / 103 passed. mypy --config-file pyproject.toml ., ruff check and ruff format --check clean in each.
• Six gate cases per package (function passes through, auto claims, agent-for-me claims, agent-for-another passes through, plain strings, old-CLI default). uipath-llamaindex had no scaffolding test file; it gets one.

🤖 Generated with Claude Code