761 Commits

Author	SHA1	Message	Date
João Moura	18c52c4e1d	[docs-freeze] docs: snapshot and changelog for v1.15.12 (#6836)	2026-08-05 22:56:24 +00:00
Vidit Ostwal	8320178697	fix(flow): clarify conversational route/handler name collision errors (#6825) ... * fix(flow): clarify route/handler name collision validation errors When @listen(...) includes the handler's own name, FlowDefinition validation fails. This change improves the error text and how it surfaces for Python Flow classes. What changed - _self_listen_error in flow_definition.py: two message variants (conversational vs default), both include the listen condition - build_flow_definition in dsl/_utils.py: wraps FlowDefinition ValidationError with the Python Flow class name - Tests for declarative and DSL-built flows; docs follow in a separate commit When each error surfaces 1. Conversational message — FlowDefinition validation when conversational.enabled is true and listen references the handler name. Example: @listen("create_video") on def create_video in a conversational flow. Surfaces via: - FlowDefinition.from_declaration(dict/yaml) → pydantic ValidationError for FlowDefinition (Value error, methods.create_video.listen listen condition...) - MyFlow.flow_definition() / MyFlow() → ValueError Invalid flow definition for MyFlow: ... (wrapped by pydantic as ValidationError for MyFlow on instantiation) 2. Default (non-conversational) message — same trigger check when the flow is not conversational. Example: @listen("publish") on def publish. Surfaces via the same paths as (1). 3. Class-name wrapper — only on the Python DSL path when build_flow_definition catches FlowDefinition ValidationError. Prepends Invalid flow definition for {ClassName}: to the underlying message from (1) or (2). Does not apply to from_declaration without a Flow class. * docs(flow): explain conversational handler naming vs route labels Document why @listen route labels must differ from handler method names and recommend the handle_* naming pattern. * docs(cli): warn against matching @listen labels to handler names Add AGENTS.md guidance for crew and flow scaffolding so coding assistants do not name handlers the same as their @listen route or event labels. * docs(cli): clarify @listen self-reference fails at validation Document that matching @listen labels to handler names raises a validation error at flow instantiation, and that the runtime loop only occurs if validation is bypassed.	2026-08-06 00:14:55 +05:30
Vidit Ostwal	fef32f43a0	feat(cli): unify scaffolding under crewai create <resource> (#6821) ... * feat(cli): add canonical `crewai create tool` command Unify tool scaffolding under the create verb and deprecate `crewai tool create` with a yellow warning while keeping backward compatibility. * feat(cli): add canonical `crewai create skill` command Unify skill scaffolding under the create verb and deprecate `crewai skill create` with a yellow warning while keeping backward compatibility. * feat(cli): add canonical `crewai create template` command Unify template scaffolding under the create verb and deprecate `crewai template add` with a yellow warning while keeping backward compatibility. * docs: document unified `crewai create` scaffolding commands Document canonical create forms for tool, skill, and template projects, note deprecated aliases, and update skills and agents-md guides. * feat(cli): extend create picker and DMN guidance for all types Show tool, skill, and template in the interactive create picker and list every supported type in the CREWAI_DMN usage error. * fix(cli): allow create tool/skill/template in CREWAI_DMN mode Only set skip_provider in DMN mode for crew creation, since tool, skill, and template paths reject that flag as a crew-only option. * test(cli): patch TemplateCommand at cli lookup site in DMN test create() resolves TemplateCommand from crewai_cli.cli, not from remote_template.main directly.	2026-08-05 16:41:27 +00:00
João Moura	b5bf858b5c	[docs-freeze] docs: snapshot and changelog for v1.15.11 (#6817)	2026-08-05 03:29:51 -03:00
PawanThakurIBM	c8f441cffa	feat(crewai-tools): add IBM Db2 search tool (#5885) ... * feat(crewai-tools): add db2 search tool * refactor(crewai-tools): improve db2 search tool implementation * feat(tools): improve DB2VectorSearchTool validation, security, and configurability * docs: add DB2SearchTool documentation * feat: add DB2 search tool * docs: update DB2SearchTool documentation * fix: address CodeRabbit review feedback * fix: validate non-empty filter_by in DB2ToolSchema * chore: trigger CodeRabbit re-review * feat: fortify DB2 tool; fixed JSON response shape, added input guards and config validation * refactor(db2): replace DB2Config with connection_string field * refactor(db2): remove dead _setup_db2 validator and importlib import * refactor(db2): remove dead guard in _connect as _disconnect() is called at the end of every _run, so self.connection is always None when _connect is called next. The 'if not self.connection' guard was dead code. * fix(db2): tighten _validate_identifier regex. Old regex allowed leading digits, multiple periods and dot-only strings (e.g. '.....' passed). * fix(db2): replace __import__ with importlib.import_module in _generate_embedding as keeping openai as a lazy optional import since it is not always required. * perf(db2): cache OpenAI client in _openai_client to avoid re-instantiation as OpenAI(api_key=...) was recreated on every _generate_embedding call. Extract into _get_openai_client() which lazily initialises and caches self._openai_client on first use, reusing it for all subsequent queries. * docs(db2): clarify tool description to mention embedding fallback * docs(db2): update README supported features to clarify embedding behaviour. 'OpenAI embedding fallback' implied it was optional. Replaced with 'Uses a custom embedding function if supplied, otherwise OpenAI embeddings.' * updated both code examples to use the correct import path and public run() method. * feat(crewai-tools): add db2 search tool * refactor(crewai-tools): improve db2 search tool implementation * feat(tools): improve DB2VectorSearchTool validation, security, and configurability * docs: add DB2SearchTool documentation * feat: add DB2 search tool * docs: update DB2SearchTool documentation * fix: address CodeRabbit review feedback * fix: validate non-empty filter_by in DB2ToolSchema * chore: trigger CodeRabbit re-review * feat: fortify DB2 tool; fixed JSON response shape, added input guards and config validation * fix(db2): address ruff and mypy linter errors * style(db2): apply ruff format to db2_search_tool.py * fix(db2-search-tool): address PR review comments - Restore DirectoryReadTool export accidentally removed; add DB2VectorSearchTool and DB2ToolSchema to crewai_tools.tools __init__ and __all__ - Align _ALLOWED_METRICS whitelist with Db2 VECTOR_DISTANCE API: replace DOT_PRODUCT/L2_DISTANCE with EUCLIDEAN_SQUARED/DOT/HAMMING/MANHATTAN - Replace ImportString fields for db2_package/db2_dbi_package with plain Any + lazy importlib.import_module in new _resolve_db2_packages() to avoid Pydantic default-validation gap where strings were never resolved at construction time - Move docs from frozen docs/v1.13.0/ snapshot to docs/edge/en/tools/database-data/ and register in docs/docs.json; update examples to match actual API (connection_string constructor, not DB2Config), correct return format, and align documented distance metrics with the whitelist * fix(db2-search-tool): resolve default and string db2 package imports dynamically * fix(db2-search-tool): export DB2VectorSearchTool and DB2ToolSchema from package-level crewai_tools * docs(db2-search-tool): fix installation command and import path in README --------- Co-authored-by: priyanshu-krishnan1 <priyanshu.krishnan1@ibm.com> Co-authored-by: GeetikaChugh24 <geetika@ibm.com> Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com> Co-authored-by: Dhruv Chaturvedi <dhruv_insights@Dhruvs-MacBook-Pro.local>	2026-07-31 09:13:33 -07:00
João Moura	3932d3fea6	[docs-freeze] docs: snapshot and changelog for v1.15.10 (#6756)	2026-07-31 14:57:21 +00:00
Gui Vieira	3266932f00	[COR-636] Remove migrated AMP documentation (#6730)	2026-07-30 13:14:34 -03:00
João Moura	112762a7fa	[docs-freeze] docs: snapshot and changelog for v1.15.9 (#6726)	2026-07-30 05:45:17 +00:00
João Moura	453676c61a	feat(tools): surface tool failures instead of reporting them as success (#6712) ... * feat(tools): surface tool failures instead of reporting them as success A tool can finish without raising and still fail to do what it was asked. Slack answers HTTP 200 with `{"ok": false, "error": "channel_not_found"}`; an MCP server sets `isError`; a CrewAI AMP action returns `API request failed: ...`. In every case the call "worked", so the error text reached the agent as an ordinary result, the agent narrated the problem in prose, and the run was recorded as a success. Concretely: five failed `slackbot_send_message` calls each rendered as "Tool Execution Completed", the task passed, and the crew passed -- with the only evidence being a sentence in the final answer. Nothing downstream could tell the difference, and an agent that keeps going on a step that silently did nothing builds the rest of its work on it. Give that outcome a type and a reaction: - `ToolFailure` -- what a tool returns instead of an error string. The agent still reads prose via `as_agent_message()`, so model behavior is unchanged; the framework now knows the call failed. - `ToolFailurePolicy` -- `ignore` (previous behavior), `warn` (default: record + emit, keep going), `raise` (abort with `ToolExecutionFailedError`). Resolved most-specific-first: tool, task, agent, crew. - `ToolFailureDetectedEvent` -- emitted before a `raise` aborts, so subscribers always observe the failure. `ToolUsageFinishedEvent` also carries a `failure` field so a trace UI can mark the call failed without correlating two events. - `tool_failures` on `TaskOutput`, `CrewOutput` and `LiteAgentOutput`, plus `has_tool_failures`, so consumers never parse a string. Detection is strictly declarative -- no string sniffing, so a tool that legitimately returns text about an error is never misread as failing. Failures come from a returned `ToolFailure`, a raised exception, MCP `isError`, a spent `max_usage_count`, or an unknown tool. Wired into all four tool-execution paths (the ReAct path and the three native function-calling implementations). Sources updated to report structurally: `MCPClient.call_tool_result()` preserves `isError` that `call_tool()` dropped, and `CrewAIPlatformActionTool` returns a `ToolFailure` for non-2xx and for caught exceptions. Two latent bugs fixed along the way: `ToolUsage` assumed every agent has a `fingerprint` (LiteAgent does not), and policy resolution now tolerates malformed values rather than letting telemetry take down a tool call. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): address review round 1 on tool-failure signalling Five real defects from Bugbot, none of them cosmetic. Tool-scoped policy never applied (high). `resolve_tool_failure_policy` read `tool_failure_policy` off the object handed to it, but every execution path passes the `CrewStructuredTool` wrapper, which never carried the attribute -- and `BaseTool` never declared it in the first place. A tool-scoped `raise`/`ignore` was silently ignored while the docs and a unit test claimed otherwise; the test passed only because it called the resolver directly with an authored tool. Declared the field on `BaseTool`, propagated it through `to_structured_tool()` and `CrewStructuredTool`, and made resolution fall back through `_original_tool` so either shape works. A failed call still printed the green "Completed" panel, then the red one. That is the terminal version of the exact bug this PR is about. Suppressed the success panel when the call reported failure. A raised tool printed twice: `ToolUsageErrorEvent` already renders a red panel, and the new failure panel repeated it. The event is still emitted -- policy and traces need it -- but the duplicate console output is gone. Both decisions now live in named predicates on `ConsoleFormatter` rather than inline in the listener closure, so they are directly testable. Unknown tools were reported on the ReAct path but silently ignored on all three native paths, so the same miss was loud or silent depending on executor style. Native paths now record `UNKNOWN_TOOL` too. This also surfaced a live `NameError`: ruff had pruned `ToolFailureReason` from `agent_utils` as unused, so the new branch would have crashed at runtime. `LiteAgentOutput` had `tool_failures` but not `has_tool_failures`, which the PR promised on all three output types -- an `AttributeError` for any caller sharing one check across result types. Testing: 16 further tests, 45 total. Two console tests were passing vacuously because `emit()` dispatches sync handlers on a thread pool, so the assertions raced the handler; they now assert on the predicates directly, and the native-path test drains the bus with `flush()` and checks the synchronously-written record. Full suite still matches baseline exactly at 377 pre-existing failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * chore: update tool specifications * fix(tools): address review round 2 and fix CI type failure CI caught a type error I should have: widening `agent` to accept a `LiteAgent` (so a standalone LiteAgent resolves its own policy) left the declared signatures behind. Widened `execute_tool_and_check_finality`, its async twin, and `ToolCallHookContext` to `Agent | BaseAgent | LiteAgent | None`, which is what those actually receive now. Seven CodeRabbit findings, all verified against the code first: `raise` was being downgraded by three enclosing handlers. With `max_execution_time` set, `_execute_with_timeout` wrapped every exception in `RuntimeError`, so `_check_execution_error` no longer recognized the passthrough and sent the task through the retry loop instead of aborting. `StepExecutor.execute` turned it into `StepResult(success=False)` and let the plan continue. `LiteAgent.kickoff` ran it through `handle_unknown_error` and printed "This is likely a bug - please report it" for what is a deliberate, configured stop. Failure records were dropped on two paths. `reset_tool_failures()` only ran in `_prepare_task_execution`, so `Agent.kickoff()` / `kickoff_async()` — which enter through `_prepare_kickoff` — accumulated records across runs. And a guardrail retry calls `execute_task` again, which resets the agent, so a tool that failed on a blocked attempt vanished from the final output entirely: a run could report zero failures having demonstrably failed one. Failures now accumulate across guardrail attempts. Writing the tests for that surfaced a further miss of my own: `Agent.kickoff()` builds its `LiteAgentOutput` in `agent/core.py` via `AgentExecutor`, not through `LiteAgent`, so `tool_failures` was always empty there regardless of the recording fix. Wired up, and the LiteAgent path now reads from whichever agent the executor was handed (`original_agent` under kickoff, `self` standalone) rather than assuming. `last_tool_failures` returns a copy, so a caller cannot mutate the agent's record or watch it shift mid-run. Testing: 7 further tests, 52 total, covering the timeout wrapper, the retry limit, kickoff reset, the kickoff output path, copy semantics and guardrail accumulation. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): make crew-scoped policy real and close the last raise leak Two findings, and the first was a documented feature that never worked. `resolve_tool_failure_policy` consulted a crew, and the docs advertised crew as a scope, but `Crew` had no `tool_failure_policy` field at all -- and even with one it was unreachable, because `BaseAgent` defaulted the policy to `WARN` rather than `None`, so resolution always stopped at the agent. Crew-level configuration was silently ignored. Fixed by making "inherit" the default everywhere instead of baking `warn` into one layer: `Crew` gains the field, and `BaseAgent`/`LiteAgent` default to `None` like `Task` and `BaseTool` already did. The resolver owns the single fallback, so the chain is genuinely tool > task > agent > crew > warn and the effective default with nothing configured is still `warn`. Reading `agent.tool_failure_policy` now returns `None` (meaning "inherit") rather than `WARN`. The other: `StepExecutor` re-raised `ToolExecutionFailedError` from its outer handler, but the nested handler around the native-to-text tooling fallback still caught it and returned `StepResult(success=False)`. An agent whose LLM lacked native tool calling would therefore not abort under `raise`. That is the third distinct place this exception was being downgraded; it now re-raises there too. Testing: 8 further tests, 60 total, including the full precedence chain walked one level at a time and crew-scoped `raise`/`ignore` driven end-to-end through `kickoff()` rather than only through the resolver -- the gap that let the original crew bug pass review. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * docs: trim comments and docstrings on tool-failure signalling Prose only -- no behavior change. Cut the module docstring, the longer class and method docstrings, the multi-line inline comments, and the verbose Field descriptions down to what actually earns its place. Net 87 lines lighter. Kept the "why" in every case where the reason is non-obvious (why the event fires before a raise, why the policy reads through the tool wrapper, why the bus needs draining in tests) and dropped the restatements of what the code already says. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): make ignore truly silent, stop caching failures, close 4 gaps Six findings from the latest review round, all verified against the code before touching it. `ignore` was not silent. `ToolUsageFinishedEvent.failure` was set before the policy ran, so traces still saw a failed call under a policy documented as surfacing nothing. Worse, the console then showed *no* panel at all: green was suppressed because `failure` was present, red was skipped because `ignore` never emits `ToolFailureDetectedEvent`. New `reportable_failure()` resolves the policy before the finished event and drops the flag under `ignore`; wired into all four execution paths. Failures were being cached. `CacheHandler.add` stored a `ToolFailure` like any other result, so a transient error became permanent for the rest of the run and every later hit re-reported a call that never re-ran. The cache now refuses to store declared failures -- fixed at the single choke point rather than at each of the four call sites. A spent `max_usage_count` was invisible on the shared native path. `BaseTool._claim_usage` returned a bare string that only the executors recognising that exact message treated as a failure. It now returns a `ToolFailure` with `USAGE_LIMIT`, so every path records it. A guardrail returning a whole `TaskOutput` replaced the output without carrying accumulated failures over, so earlier attempts vanished from `CrewOutput.tool_failures`. New `merge_tool_failures()` combines and deduplicates, and the retry-rebuild path uses it too. A hook-blocked call inherited a cached failure and attributed it to a call that never ran. Now cleared. Not reachable through the built-in cache once failures stop being cached, so the test injects a custom cache handler that does retain them -- verified to fail without the guard. Also removed a `datetime` import left unused by the earlier console-test rewrite. Testing: 13 further tests, 73 total. Full suite matches baseline exactly at 377 pre-existing failures; the usage-limit suites that `_claim_usage` touches pass unchanged; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): let raise through the parallel native path, guard all handlers Chasing down CodeRabbit's note about callers of execute_single_native_tool_call turned up a fifth place this exception was being downgraded: the experimental executor's parallel branch wrapped future.result() in a broad except and folded the abort into a fake tool result, so the remaining parallel calls carried on. The sequential path and crew_agent_executor's parallel branch were already fine. Five separate handlers have swallowed this during review, so added a guard test asserting the passthrough at every site rather than trusting the next one gets spotted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): keep a failed tool out of the final answer, finish crew scope Three more findings, all confirmed against the code. A failed `result_as_answer` tool still became the task's output. The native paths already excluded raised errors and hook blocks from short-circuiting, but not declared failures -- so an error message silently became the answer, which is the exact shape of bug this PR exists to prevent. Fixed on all paths, and there were three independent override points, not one: `ToolResult.result_as_answer` in tool_utils, the `execution_result` finality checks in both executors, and `process_tool_results()`, which reads `agent.tools_results` back separately. The first two fixes alone left the behavior unchanged; only the third made the test pass. `ToolUsage` never received a crew, so a crew-level `ignore` half-applied: recording and `ToolFailureDetectedEvent` stayed quiet, but the flag was still attached to `ToolUsageFinishedEvent`. It now takes and stores `crew`. `CrewAgentExecutor.invoke`/`ainvoke` routed a deliberate stop through `handle_unknown_error`, printing "An unknown error occurred" on verbose runs. LiteAgent already special-cased this; both now do. Testing: 5 further tests, 79 total, including that a *successful* `result_as_answer` tool still short-circuits. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): report malformed tool args, correlate the failure event Two findings from the latest round. Malformed native tool arguments returned early with a plain error dict and never reported a failure, so `ToolFailureReason.INVALID_INPUT` was declared but unreferenced -- a bad tool call was absent from records, events and `raise` aborts. `parse_tool_call_args` now carries an INVALID_INPUT failure on the error dict and both executors report it before returning. `ToolFailureDetectedEvent` never set `agent_id`, so a trace could not tie it to a specific agent instance. Fixing that exposed the same gap running the other way: `ToolUsage`'s own started/finished/error events never set `agent_id` either, so on the ReAct path the paired finished event had nothing to correlate against. Both now set it. Set explicitly rather than via `from_agent`, which would also overwrite `agent_role` and lose the `_original_role` preference those events already apply -- a behavior change that has nothing to do with correlation. Testing: 5 further tests, 84 total, asserting the ids match between the failure event and its paired finished event. One existing test pinned the exact key set of the parse-error dict and was updated for the new key. Full suite matches baseline at 377 pre-existing failures; the one apparent addition was the known `test_trace_enable_disable` order-flake, confirmed by re-running rather than assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): scope failure accumulation per execution, drop deprecated executor Two review requests from @lorenzejay. Accumulation no longer lives as mutable state on the shared agent. A ContextVar collector is opened around each execution -- task, kickoff, and each guardrail retry -- and the output reads that collector directly instead of copying the agent's list. ContextVars are copied per asyncio task and per thread, so concurrent executions cannot see each other's records, and nesting is safe for retries. `last_tool_failures` prefers the active collector and falls back to the last completed execution, so the accessor is correct during a run too. The per-execution reset that caused the erasure is gone. Reproducing this took some digging and the finding is worth recording: crew tasks *cannot* hit it, because `AgentExecutor` refuses concurrent reuse of one instance and raises. `agent.kickoff()` has no such guard, and there the bug reproduces exactly as reported -- two concurrent kickoffs each returned two records. The regression test forces the overlap with a barrier so it is deterministic rather than timing-dependent, and I verified it reports [2, 2] against the old behavior and [1, 1] now. Removed the tool-failure integration from `CrewAgentExecutor` entirely; that file is back to its state on main. Note the shared ReAct helper it calls still records failures, since that is common code rather than new behavior in the deprecated file -- so a `raise` policy will be swallowed by that executor's generic handler. Flagged on the PR rather than papered over. Testing: 89 total. Two tests I wrote for this were vacuous on the first attempt -- they passed against the simulated pre-fix code -- so each concurrency test was checked against the old behavior before being kept. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): report malformed calls everywhere, drop the unused block reason Four findings. `execute_single_native_tool_call` swallowed a JSON decode error into an empty args dict and ran the tool with no input at all -- worse than not reporting it. It now routes through `parse_tool_call_args` like the executors do, so the StepExecutor/planning path reports INVALID_INPUT and returns instead of executing. That also removes a duplicated inline parse. The ReAct path returned a `ToolUsageError` message as an ordinary result without reporting it, so a malformed call there was invisible while the equivalent native failure was recorded. Now reported as INVALID_INPUT too. `Agent.kickoff` opened a collector but no longer reset the agent-level list, so `last_tool_failures` grew across kickoffs. Reset restored, matching task execution. `ToolFailureReason.BLOCKED_BY_HOOK` was declared and never produced. Rather than start reporting hook blocks as failures, the member is removed: a block is a deliberate decision by the hook author, and treating it as a failure would make `raise` abort on an intentional veto. Added a guard test that every remaining reason is actually produced somewhere, so a dead member cannot reappear -- the same smell that flagged INVALID_INPUT last round. Also switched the deprecation guard test to a single import style. Testing: 6 further tests, 95 total, including that the tool does not run when its args fail to parse. Full suite matches baseline at 377 pre-existing failures; mypy clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): merge failures across kickoff guardrail retries, cancel siblings Kickoff guardrail retries discarded the blocked attempt's failures. Each retry calls `_execute_and_build_output`, which opens a fresh collector and builds a new output, so a run could report zero failures having demonstrably failed one -- the same bug already fixed on the task guardrail path, which merges. Now merged there too. Verified the test fails without the fix. Under `raise`, one parallel native tool aborting left its siblings running: the pool waited for them and pending ones still started. It now shuts the pool down with `cancel_futures=True` so a not-yet-started sibling never runs. Threads already in flight cannot be interrupted in Python, so a concurrent tool may still complete before the abort surfaces; that is noted at the call site rather than left implied. Also satisfied CodeQL by materialising the enum in the guard test's loop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-07-29 19:30:14 -07:00
Lucas Gomide	d52d0a1628	feat: emit FlowFailedEvent when a flow execution fails (#6718) ... * feat: emit FlowFailedEvent when a flow execution fails A failed flow never emitted a terminal lifecycle event, so the `flow_started` scope stayed open and consumers such as tracing closed the root span with a generic orphaned message instead of the real error. `kickoff_async` and the resume path now emit `FlowFailedEvent`, paired with `flow_started` and carrying the exception, after draining pending handlers and background memory writes. The resume path also emits the `MethodExecutionStartedEvent` it was missing for the method being resumed, so its finished or failed event pairs with its own scope instead of popping the flow's. * fix: skip FlowFailedEvent when the run never opened a scope The `kickoff_async` try block starts before `FlowStartedEvent` is emitted, so an abort in the execution-start hooks, in input handling or in state restore emitted a `flow_failed` with no opener, which pops an unrelated scope and warns about an empty scope stack. The failure event is now gated on the flow scope actually being open, either from this kickoff's `flow_started` or from a restored deferred session scope.	2026-07-29 14:44:55 -04:00
Lorenze Jay	f15844b219	Lorenze/imp/skills progressive disclosure (#6675) ... * skills progressive disclosure * skills progressive disclosure * improving progressive disclosure * addressed comment * fix test --------- Co-authored-by: João Moura <joaomdmoura@gmail.com>	2026-07-28 09:33:43 -07:00
João Moura	e9caf1e1b8	[docs-freeze] docs: snapshot and changelog for v1.15.8 (#6703)	2026-07-28 15:05:44 +00:00
João Moura	2e95bfb4e8	fix(tools): sandbox FileWriterTool writes and fix file tool rough edges (#6692) ... * fix(tools): sandbox FileWriterTool writes and fix file tool rough edges FileReadTool confined reads to the working directory, but FileWriterTool only checked that `filename` stayed inside `directory` — and `directory` itself is an LLM-supplied schema field. An agent could therefore write anywhere the process had permission to, including ~/.ssh and site-packages, while the reader refused to read back what the writer had just written. FileWriterTool was the only filesystem tool in the package that did not go through validate_file_path; files_compressor_tool validates even its output path. Writes are now confined to base_dir (the working directory by default): the resolved directory must sit inside base_dir, and the resolved file must sit inside that directory. The pre-existing filename containment check is kept as-is and still applies even when the unsafe-paths escape hatch is on, so no existing guarantee is weakened. Both tools gain a base_dir field so a developer can widen the sandbox deliberately instead of reaching for the process-wide CREWAI_TOOLS_ALLOW_UNSAFE_PATHS kill switch. FileReadTool also stops rejecting a file_path given to its own constructor: that is developer-declared intent, and declaring one file does not expose its siblings. Also fixed: - FileReadTool scanned the whole file when reading a line window; it now stops via islice once the requested lines are collected. - FileWriterTool._run(**kwargs) made the documented positional call signature raise TypeError and turned a missing overwrite into "error accessing key". It now takes named parameters in the documented (filename, content, directory) order. - A directory naming an existing file reported "already exists and overwrite option was not passed" even with overwrite=True; it now explains the real problem. - Subdirectories inside filename are created, matching what passing directory already did. - Both tools now write and decode UTF-8 by default instead of the platform locale encoding, with an encoding field to override. The docs already claimed UTF-8 and recommended the writer to Windows users. - The writer's schema fields had no descriptions for the LLM. - Docs claimed FileReadTool parses JSON into a dict (it never has), shipped a snippet that raised TypeError, and did not mention the path sandbox. The writer README also began with a stray "Here's the rewritten README" preamble. BREAKING CHANGE: FileWriterTool no longer writes outside the working directory. Pass base_dir to authorize a different tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: update tool specifications * fix(tools): make the declared FileReadTool file reachable by agents Addresses review feedback on #6692. The constructor-path exemption did not actually work the way an agent calls the tool. The description only advertises a redacted label (the basename, when the file sits outside the sandbox), but resolution required the exact absolute path, so the model's call was sandboxed and the declared file was never read. Worse, file_path was a required schema field, so the long-documented "call with no arguments to read the default file" raised a validation error instead: FileReadTool(file_path="/outside/declared.txt") .run() -> ValueError: validation failed .run(file_path="declared.txt") -> Error: File not found .run(file_path="/outside/declared.txt") -> works, but the model was never told this path file_path is now optional in the schema, so omitting it reads the default, and the declared file is addressable by the label the description shows the model as well as by its real path. Declaring one file still does not expose its siblings. The declared path is also pinned to its real path at construction, so a later chdir cannot silently repoint it at a different file — previously a relative constructor path re-resolved against the new working directory on every call. Also guards the writer's filepath resolution, which could raise ValueError out of _run for a filename containing a null byte, breaking the contract of always returning a descriptive string. The directory and read paths were already guarded. Adds docstrings to strtobool and both _run methods, corrects an Arabic tanween spelling and a kaf-as-descriptor calque in the localized read docs, and regenerates tool.specs.json for the schema change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): anchor the declared read path to base_dir, not the cwd Addresses the second round of review feedback on #6692. The previous commit pinned a relative constructor file_path with os.path.realpath, which anchors to the working directory, while both format_path_for_display and validate_file_path anchor a relative path to base_dir. With the two roots disagreeing, the same relative string meant two different files — and the tool served the cwd one under a label that looks like it belongs to the sandbox: FileReadTool(file_path="data.txt", base_dir="/allowed") # cwd=/work label advertised to the model -> "data.txt" run(file_path="data.txt") -> contents of /work/data.txt That reads a file from outside base_dir, so it was a sandbox escape introduced by the exemption itself, not just a wrong-file bug. Resolution now goes through a single _resolve_against_base helper that anchors relative paths exactly the way the sandbox does, so the pinned path, the advertised label and the containment check all agree. Covered by test_relative_declared_path_anchors_to_base_dir. Also softens "always readable" to "always allowed past the containment check" in the docstring, README and docs, since bypassing containment does not guarantee the read succeeds — it can still fail on a missing file, a directory, or permissions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): tell the LLM about the path sandbox in tool descriptions Addresses the low-confidence notes from the Copilot review on #6692. Both tools' descriptions were pre-sandbox wording, so the model learned about containment only by attempting a path and reading the error back. Both now state that access is confined to the tool's allowed directory and that a path resolving outside it is rejected. The wording deliberately says "the tool's allowed directory" rather than "the working directory", because the root is base_dir when one is set, and naming the absolute root would leak it into the prompt — the same reason paths are redacted in errors. Not changed: the notes also suggested advertising `encoding`. That is a constructor-only field the model cannot set, so describing it to the LLM would be misleading. Also fixes a test docstring that contradicted its own assertion — the public run() path does raise on schema validation failure, which is what the test asserts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): anchor base_dir at construction so the sandbox cannot move Addresses the third review round on #6692. Both remaining findings came from the same habit: storing an unanchored string and re-resolving it later. A relative base_dir was kept verbatim and re-resolved against getcwd() on every call, while the declared file was pinned once at construction. After a chdir the sandbox root moved but the declared default did not, so one tool applied two different roots. base_dir is now resolved once — in the reader's __init__, and via a field_validator on the writer so it also applies on the model_validate path. That also covers the serialization concern. model_dump drops the private pin, and __init__ re-runs on restore, so a relative file_path was re-anchored against whatever the working directory happened to be at load time. With base_dir anchored, restore rebuilds the identical pin. The residual case is a relative file_path with no base_dir, where the sandbox root is the working directory too — so both move together and the tool stays self-consistent. Covered by test_declared_path_survives_a_serialization_round_trip and test_relative_base_dir_is_anchored_at_construction on both tools. Also corrects the writer's 'directory' description, README and docs: the default resolves inside the tool's allowed directory, which is base_dir when one is set, not always the working directory. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-07-28 02:20:26 -07:00
João Moura	97981ed31b	feat(tools): add WaitTool for pausing on long-running jobs (#6690) ... * feat(tools): add WaitTool for pausing on long-running jobs Agents that kick off out-of-band work (a sandbox build, a deployment, an async API job) have no way to let clock time pass: they either poll in a tight loop or give up before the work finishes. WaitTool pauses for a given number of seconds, with an optional reason echoed back for traces. A single call waits at most max_seconds (default 300, configurable). Longer requests are clamped to the cap and the result says so, so the model calls again rather than failing. Sync and async execution are both implemented; stdlib only, no new dependencies. The tool description spells out when to reach for it (builds, deploys, batch jobs, async polling, backoff) and when not to, so models pick it up for the right reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): enforce non-negative wait on positional calls, fix doc snippets BaseTool.run() skips args_schema validation when called with positional arguments, so tool.run(-5) reached time.sleep(-5) and failed with an unrelated error. _resolve_duration now enforces the seconds >= 0 contract itself, covered for both run() and arun(). Docs and README examples are now self-contained: check_build_status_tool is defined with the @tool decorator instead of referenced out of nowhere, and the async example awaits inside asyncio.run() rather than at top level. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: point the wait tool card at the edge path Unprefixed links resolve against the default docs version (v1.15.7), where the wait tool page does not exist, so the card 404'd in the broken link check. Prefixing with /edge matches how other edge pages link. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): never cache waits and keep the advertised cap accurate Two issues from review, both confirmed against the code. Waits inherited the default cache_function, which always allows caching. With crew cache enabled, a repeat call with the same arguments returned "Waited N seconds." straight from the cache without sleeping, turning a poll-wait-check loop into a busy loop. WaitTool now declares a cache_function that always refuses. The description advertising the cap was only rebuilt when max_seconds reached __init__ without an explicit description. Passing both (as a platform building from tool.specs.json init params would), calling model_validate, or assigning max_seconds left the text claiming 300 seconds while clamping to something else. A model_validator now derives the description from max_seconds on construction, validation, and assignment, and leaves a caller-supplied description untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): reject NaN waits and pluralize single-second results _resolve_duration now rejects NaN with its own message instead of letting time.sleep raise "Invalid value NaN (not a number)" from a positional call. Infinity keeps clamping to the cap like any other oversized wait. Result and description text no longer says "1 seconds". Tests use the public WaitTool().description as the baseline rather than reaching for module-private helpers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 17:12:27 -07:00
Ossama Alami	daa7019898	docs(llms): refresh model availability guidance (#6676) ... * docs(llms): refresh model availability guidance * docs: clarify structured output support * docs: address LLM guide review feedback * docs: refresh streaming model examples	2026-07-26 16:13:36 -07:00
João Moura	1870b444e7	[docs-freeze] docs: snapshot and changelog for v1.15.7 (#6673)	2026-07-26 11:19:47 -07:00
Lorenze Jay	213d9485fe	docs: snapshot and changelog for v1.15.7a1 (#6665)	2026-07-26 14:04:16 -03:00
João Moura	cc0759854d	fix(skills): resolve registry skills through the runtime's CrewAI+ client (#6658) ... * fix(skills): resolve registry skills through the installed AMP client Skill downloads built their own `PlusAPI` and authenticated it from `CREWAI_USER_PAT`, the platform integration token, or the saved CLI login. Managed runtimes have no user credential to offer: they install a client of their own, which `load_agent_from_repository` already resolves through, so Agent Repository lookups worked while the skill downloads beside them failed with 401. Skills now resolve their client the same way, via `resolve_plus_client()` next to the hook it reads. A client that can't fetch skills falls back to environment credentials and warns, so older runtimes behave as they do today. `resolve_plus_response()` shares the sync/async bridging both lookups need, since `PlusAPI` is synchronous while managed clients are not. Version pinning, which the same bug was hiding: - Registry refs accept `@org/name@version`, and `@org/name@v1.2.0` since people write it both ways. `parse_skill_ref()` returns a `SkillRef(org, name, version)`; `parse_registry_ref()` keeps its `(org, name)` shape and drops the pin, so existing callers are unaffected - Agent Repository agents record a version per skill, which was parsed off the response and dropped. Those pins now travel with the refs, so publishing a new version of a skill no longer changes every agent that uses it - A pinned ref only accepts a project-local copy declaring that version in its `metadata.version` frontmatter, and the cache reports a miss when the version it recorded differs — so a pin re-resolves rather than loading another version. Unpinned refs keep hitting the cache as before - An unknown pin fails instead of quietly falling back to the newest version Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(skills): reject a blank version pin instead of floating to latest A blank `version` passed to `download_skill` read as "unpinned" and quietly resolved the latest version, which is not what a caller supplying one asked for — and it disagreed with `parse_skill_ref`, which already rejects empty pins. Not reachable through `resolve_registry_ref` or the Agent Repository auto-pinning, both of which only ever pass a non-empty version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(skills): carry the caller's context into the worker thread When resolve_plus_response bridges an async client from inside a running loop it runs the coroutine on a worker thread, which starts with empty ContextVars. A client reading runtime state there — the platform integration token, flow context — would see defaults rather than the caller's values, which is hard to diagnose from the resulting auth or routing failure. Copy the context across, matching how the parallel-summarization bridge in this module already does it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 13:27:29 -03:00
Lorenze Jay	b3aaaab023	[docs-freeze] docs: snapshot and changelog for v1.15.6 (#6632)	2026-07-24 20:30:21 +00:00
Lucas Gomide	3bb87532da	fix: dispatch execution_end hook on failed crew and flow executions (#6607) ... * fix: dispatch execution_end hook on failed crew and flow executions The `execution_end` interception point only fired after a successful kickoff, so consumers never learned about failed runs. Crew kickoff paths (`kickoff`/`akickoff`) and the flow runtime (`kickoff_async`, `resume_async`) now dispatch it on the failure path too, with new additive `status` ("completed"/"failed") and `error` fields on `ExecutionEndContext`. Pairing flags guarantee exactly-once dispatch, keep the start/end pairing invariant, and the original exception propagates unchanged. * fix: track execution_end pairing per invocation for reentrant flows Reentrant kickoffs on the same Flow instance are supported (usage aggregation already accommodates them), but the instance-level pairing booleans let an inner kickoff's completion mark the outer execution as ended, skipping the outer failure's `execution_end`. The pairing state now lives in each `kickoff_async` invocation's locals, and the resume path passes a per-invocation holder into `_resume_async_body`. Crew keeps its instance flags since crew kickoffs are not reentrant on the same instance (`kickoff_for_each` copies the crew).	2026-07-21 15:25:06 -04:00
Vinicius Brasil	ce739e28c7	[docs-freeze] docs: snapshot and changelog for v1.15.5 (#6602)	2026-07-20 12:33:16 -04:00
Vinicius Brasil	69c0308f2c	[docs-freeze] docs: snapshot and changelog for v1.15.4 (#6583)	2026-07-17 14:33:07 +00:00
João Moura	f0704ebb22	feat(skills)!: promote Skills Repository out of experimental (#6579) ... * feat(skills)!: promote Skills Repository out of experimental The registry-backed Skills Repository (crewai skill create/publish/ install/list, @org/name refs, global cache) is now mainline: - CLI: `crewai skill ...` is a top-level group; the CREWAI_EXPERIMENTAL gate and the now-empty `crewai experimental` group are removed. - Runtime: registry.py, cache.py, and events.py move from crewai.experimental.skills into crewai.skills next to the loader; the require_experimental_skills() gate is gone. crewai.experimental.skills remains as a deprecated re-export shim. - Docs: concepts/skills now leads with the CLI workflow and documents the create -> publish -> install lifecycle. Linear: n/a (requested promotion) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(skills): org-scoped publish only + docs in all languages Skills are always scoped to the publishing organization, like tools: drop the --public/--private flags from `crewai skill publish` and always send is_public=False to the registry. CLI tests assert the flag is rejected and the API never receives a public publish. Translate the new CLI-first Quick Start and the create -> publish -> install lifecycle section into ar, pt-BR, and ko concepts/skills docs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): address review comments on the promotion PR - Back-compat shim now aliases the old submodules in sys.modules so `crewai.experimental.skills.registry/cache/events` imports (and patch targets) resolve to the real crewai.skills modules, not just the package-root re-exports. - `crewai skill publish` actually enforces the git-state check that --force claims to skip: unsynced repos block publishing (mirroring tool publish); standalone skill dirs outside any git repo publish without a check. - Explicit UTF-8 encoding on SKILL.md and cache-metadata reads/writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): fail closed when git state cannot be validated on publish Follow deploy's pattern: construct git.Repository(fetch=False) and only treat "not a Git repository" as skippable — any other git error (fetch/auth/misconfiguration) now blocks publish with a --force escape hatch instead of silently bypassing the sync check. Also single-style imports in the shim test (CodeQL) with the dotted shim import covered via importlib. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): fetch before sync check on publish; bump mcp past advisories Publish now refreshes remote-tracking refs (repository.fetch()) before is_synced(), so ahead/behind is judged against the actual remote rather than stale local refs; a failing fetch blocks publish with the --force escape hatch. Adds a fail-closed test for fetch errors. Raise mcp to >=1.28.1,<2 (locks 1.28.1): the ~=1.26.0 pin blocked GHSA-hvrp-rf83-w775 / GHSA-jpw9-pfvf-9f58 (fixed 1.27.2) and GHSA-vj7q-gjh5-988w (fixed 1.28.1), which were failing pip-audit on this PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Vinicius Brasil <vini@hey.com>	2026-07-17 14:21:15 +00:00
Jesse Miller	df2e68fe0a	docs: add Flows in Studio documentation (#6575) ... * docs: add Flows in Studio documentation Documents the new Flows build mode in Studio: why deterministic workflows with agentic steps matter, the three core node types (Single Agent, Crews, Router), and Agent Repository publish/pull sync across organizations. Includes a rollout banner for the week of July 20th, English source plus pt-BR, Korean, and Arabic translations, and nav entries for both edge and v1.15.2 (Crew Studio group renamed to Studio). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: limit Flows in Studio docs to edge version Versioned snapshots are updated by a separate script, so remove the v1.15.2 copies and revert its nav changes; the page now lives only under edge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 20:05:59 +00:00
Vinicius Brasil	475ce6cb6a	[docs-freeze] docs: snapshot and changelog for v1.15.3 (#6577)	2026-07-16 19:42:53 +00:00
Vinicius Brasil	a2b0af6bc8	docs: snapshot and changelog for v1.15.3a2 (#6574)	2026-07-16 18:55:47 +00:00
Vinicius Brasil	c5ac2d93b4	docs: snapshot and changelog for v1.15.3a1 (#6567)	2026-07-16 14:22:06 -03:00
Lucas Gomide	da9902da4f	docs: group execution hooks and document all hook contexts (#6548) ... * docs: group execution hooks and document all hook contexts The hooks pages sat flat in the learn nav and only documented the LLM and tool call contexts, with examples built on the legacy decorators. Groups them under a collapsible "Execution Hooks" section, adds `step-hooks` and `execution-boundary-hooks` pages covering every hook context from source, reworks the LLM and tool pages to lead with `@on` while keeping the decorators, and links the orphaned `before-and-after-kickoff-hooks` page into the group. * docs: prefix hook cross-links with /en so they resolve in edge The new edge-only hooks pages linked each other with versionless paths like `/learn/step-hooks`, which mintlify resolves against the frozen default version where those pages do not exist, breaking the CI link check. Uses the `/en/learn/...` form the other edge pages already use. * docs: use /edge prefix for links to edge-only hooks pages The `/en/learn/...` form still resolves against the default frozen version, where `step-hooks` and `execution-boundary-hooks` do not exist yet, so the link checker kept failing. Links now use the explicit `/edge/en/learn/...` form, matching how `consuming-streams.mdx` linked to edge-only streaming pages before they were frozen.	2026-07-15 08:17:52 -04:00
Lucas Gomide	0e5d0ecfb9	feat: add step interception points and rework execution hooks docs around @on (#6518) ... * feat: add pre_step and post_step interception points on task execution Introduces `StepContext` and the two step points in the dispatcher, and wires them around agent execution in `task.py` (sync and async paths): `pre_step` fires after `TaskStartedEvent` with the task context as payload, `post_step` fires before `TaskCompletedEvent` with the `TaskOutput`, and hook replacements are rebound in both directions. * feat: wire pre_step and post_step on flow method execution Dispatches the step points around each flow method with kind="flow_method": `pre_step` receives the dumped call params and maps returned edits back onto args/kwargs, `post_step` can rewrite the method result before it is recorded. Conformance tests cover per-method firing and output rewriting. * docs: rework execution hooks page around the @on api Replaces the standalone interception hooks catalog with a single `execution-hooks.mdx` page that teaches `@on` as the primary way to write hooks, covering the full ten-point catalog across task, flow, and LLM execution. The legacy per-point decorators stay documented in a closing section, and the `docs.json` navigation drops the removed page.	2026-07-14 14:47:18 -04:00
Lorenze Jay	7baf8f9ba1	improving custom OpenAI urls (#6490) ... * Support legacy OpenAI base URL env var * Add custom OpenAI-compatible endpoint support * Refactor OpenAI completion module test to restore original module state - Added logic to save and restore the original OpenAI completion module during the test to prevent issues with class re-imports affecting subsequent tests. - Ensured that the test checks for the presence of the module and its attributes only after the module is properly reloaded. - Improved test reliability by avoiding potential failures due to module state changes across tests. * addressing comments	2026-07-09 15:30:16 -07:00
Lorenze Jay	289686ab49	[docs-freeze] docs: snapshot and changelog for v1.15.2 (#6479)	2026-07-07 19:05:05 -07:00
Renato Nitta	fc41c42773	docs: update language from Rules to Policies to match the new dashboard changes (#6471) ... * docs: rename ACP rules to policies across edge and v1.15.1 locales with redirects * docs: point ACP policies pages at the new policy screenshots * docs: address review — revert frozen v1.15.1 edits and fix redirect ordering * docs: prefix edge policies cross-links so they resolve until the next version cut * docs: move policies redirects above all wildcard redirects	2026-07-07 15:43:51 -03:00
Lorenze Jay	559a9c65c4	docs: snapshot and changelog for v1.15.2a2 (#6422)	2026-07-01 15:14:56 -07:00
Lorenze Jay	b37505bcf9	Add streaming docs to the navigation (#6403)	2026-06-30 16:00:38 -07:00
Lorenze Jay	694881c7bf	docs: snapshot and changelog for v1.15.2a1 (#6398)	2026-06-30 13:17:53 -07:00
Lorenze Jay	8eed457e70	Define stream frame protocol for flows (#6391) ... * Define stream frame protocol for flows * Add direct LLM streaming helpers * Unify flow streaming frame items * Update flow streaming integration properties * Drop stream frame debug runner example * Address streaming contract review feedback * Replay cached stream frame projections * Remove stream frame version field * Fix streaming contract docs link * Preserve LLM instance state for stream events * Address streaming review cleanup	2026-06-30 10:53:48 -07:00
Lucas Gomide	e8dced8a2d	docs: document Cost Limit rule type in Agent Control Plane (#6387)	2026-06-29 14:56:13 -03:00
Lucas Gomide	2b87098279	fix: cut docs version nav from Edge so new pages aren't dropped (#6349) ... * fix: freeze docs version nav from Edge instead of previous release The docs cut copied every Edge file into the new `docs/v<X.Y.Z>/` snapshot but built that version's `docs.json` navigation by cloning the previous frozen release and only rewriting path prefixes. Pages added to Edge since the last release were therefore copied to disk yet never linked in the version selector, which is why the v1.15.0 cut shipped without the Datadog guide. `_build_new_entry` now clones the Edge nav entry and rewrites `edge/<locale>/` to `v<new>/<locale>/`, so promoting Edge to Latest carries every current page and nav restructuring. * docs: link the v1.15.0 Datadog guide dropped during the cut The v1.15.0 freeze copied `enterprise/guides/datadog` into the snapshot for every locale but never linked it in `docs.json`, because the cut cloned the v1.14.7 nav instead of Edge. This backfills the missing nav reference in the `en`, `pt-BR`, `ko`, and `ar` v1.15.0 blocks so the already-shipped page is reachable from the version selector. Pairs with the `_build_new_entry` fix that prevents future cuts from dropping pages. * docs: link the v1.15.1 Datadog guide dropped during the cut The v1.15.1 cut ran before the freeze-from-Edge fix landed, so it inherited the same bug as v1.15.0: `enterprise/guides/datadog` was copied into the snapshot for every locale but never linked in `docs.json`. This backfills the missing nav reference in the `en`, `pt-BR`, `ko`, and `ar` v1.15.1 blocks so the page is reachable from the version selector.	2026-06-29 10:03:26 -04:00
Lucas Gomide	4379c45804	docs: drop CREWAI_LOG_FORMAT references from Datadog guide (#6307) ... JSON-formatted stdout is now the only supported log shape in CrewAI Enterprise — the `CREWAI_LOG_FORMAT=json` opt-in env var is gone and no longer needs to be configured in AMP. Removes the "Enabling JSON output" section, the env-var setup step, the troubleshooting check, and the `legacy text mode` comparison across the four locale copies (`en`, `ko`, `pt-BR`, `ar`) of `docs/edge/<lang>/enterprise/guides/datadog.mdx`.	2026-06-29 09:04:49 -04:00
João Moura	6491f5a663	[docs-freeze] docs: snapshot and changelog for v1.15.1 (#6367)	2026-06-27 03:50:32 -03:00
Lorenze Jay	e716f3de8b	docs: snapshot and changelog for v1.15.1a1 (#6362)	2026-06-26 15:16:43 -07:00
João Moura	2771c02f45	docs: improve coding agent setup CTA (#6344) ... * docs: improve coding agent setup CTA * docs: move home CTA to published index * docs: address CTA review feedback	2026-06-26 05:10:55 -03:00
Lorenze Jay	b6fbe078d6	[docs-freeze] docs: snapshot and changelog for v1.15.0 (#6340)	2026-06-25 16:17:40 -07:00
Vinicius Brasil	178c2d212c	docs: snapshot and changelog for v1.14.8a5 (#6329)	2026-06-24 17:31:32 -07:00
Jesse Miller	5827abbc17	docs: nest One Card per Step under Crew Studio and drop rollout banner (AGE-107) (#6317) ... The page itself already landed on main via #6247. This rebases onto main and applies the two remaining changes: - Nest crew-studio + merged-step-card into a collapsible "Crew Studio" nav group (pencil icon), across edge and v1.14.7 in en, pt-BR, ko, ar. - Remove the temporary "Rolling out" Note banner (feature ships today). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 13:36:49 -04:00
Vinicius Brasil	9d0e3a841b	docs: snapshot and changelog for v1.14.8a4 (#6319)	2026-06-24 09:19:33 -07:00
Vinicius Brasil	f2a074e35b	docs: snapshot and changelog for v1.14.8a3 (#6310)	2026-06-23 14:11:31 -07:00
Vinicius Brasil	221dfdb08e	Consolidate crewai run and crewai flow kickoff (#6296) ... Make `crewai run` the single execution path for crews and flows, with `crewai flow kickoff` kept as a deprecated compatibility alias.	2026-06-22 20:44:08 -07:00
Vinicius Brasil	9db2d44766	Add typed output schemas for CrewAI tools (#6236) ... Currently, tools have a strong input contract through `args_schema`, but no output contract. This means that anything a tool outputs is converted to string. Not only the contract is weak, but the "invisible" conversion to string can have unexpected effects when the tool returns complex objects like dicts and arrays. With this PR, a tool can _optionally_ define an output contract with `output_schema`. CrewAI validates the raw result and sends the agent JSON. ```python class ProductResult(BaseModel): sku: str name: str in_stock: bool class ProductLookupTool(BaseTool): name: str = "Product Lookup" description: str = "Look up product availability by SKU." def _run(self, sku: str) -> ProductResult: return ProductResult(sku=sku, name="USB-C dock", in_stock=True) ``` If the result does not match the schema, CrewAI warns and falls back to `str(raw_result)` instead of failing the run: ```python @tool("Product Lookup", output_schema=ProductResult) def product_lookup(sku: str) -> dict[str, object]: return {"sku": sku, "name": "USB-C dock", "in_stock": True} #=> RuntimeWarning: Failed to validate or serialize output from tool 'Bad Product Lookup' using output_schema 'ProductResult'... Falling back to str(raw_result). ``` This is additive and non-breaking. Existing tools do not need to change. Tools without `output_schema` keep the old string behavior. Invalid typed outputs warn and fall back to the old formatting path.	2026-06-19 14:33:51 -07:00
Jesse Miller	cf04181190	docs: add "One Card per Step" Studio page (AGE-107) (#6247) ... * docs: add "One Card per Step" Studio page (AGE-107) Document the merge of the task and agent nodes into a single step card on the Studio canvas. Written as evergreen present-tense feature docs with a dated rollout banner (June 24th) for the pre-launch customer announcement; the banner is the only time-bound content and is flagged for removal after ship. Added in edge + v1.14.7 across en, pt-BR, ko, and ar, with nav entries in docs.json and three canvas/editor/swap screenshots. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: bump bedrock agentcore dependencies --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: alex-clawd <alex@crewai.com>	2026-06-19 13:10:25 -04:00