- Introduced `ctx.agent` and `ctx.llm` objects in the context API for improved agent-to-agent (A2A) and direct LLM calls.
- Added methods for single and parallel agent calls, including `Call`, `All`, `Any`, and `Race`, enabling flexible communication between agents.
- Enhanced documentation with detailed method summaries, parameters, and examples for better developer guidance on using the new APIs.
- Updated `logrus` dependency from v1.9.3 to v1.9.4 and `golang.org/x/sys` from v0.38.0 to v0.40.0 for improved functionality and security.
- Introduced a `Fork` method in the agent context to create child contexts for concurrent agent and LLM calls, preventing race conditions on shared state during batch operations.
- Enhanced the `Orchestrator` methods to utilize forked contexts, ensuring independent execution of agent calls without interference.
- Added initialization for the Agent JSAPI factory to support ctx.agent.* methods, improving agent interaction capabilities.
- Introduced a new agent object in the JSAPI context for calling other agents, enhancing modularity.
- Implemented an OnMessage callback in the context options to handle messages sent via ctx.Send(), allowing for more flexible message processing.
- Added tests for saving plain text and Chinese text directly, ensuring proper handling of content without data URI encoding.
- Updated the `parseDataURI` function to support plain text storage, returning the correct content type and data bytes.
- Improved the `getAssistants` method to support nested assistants, enhancing directory scanning for assistant pages.
- Refactored the `Page` method to accommodate assistant IDs with nested structures, improving route handling for pages.
- Removed the validExts field from test cases, streamlining the filename generation tests.
- Enhanced validation to ensure filenames have a proper extension format and are not empty, improving test robustness.
- Updated comments for clarity on expected filename behavior based on content type.
- Eliminated debug print statements for the "thinking" parameter and the full request body in the OpenAI provider, streamlining the request construction process.
- Maintained the functionality of including the "thinking" parameter for models that support reasoning/thinking mode, ensuring improved performance without unnecessary logging.
- Added support for a new "thinking" parameter in the request body for models that support reasoning/thinking mode, improving functionality.
- Updated the request body construction to include debugging output for the full request body, aiding in troubleshooting and development.
- Ensured that the model and other settings are retrieved from the connector, maintaining consistency in configuration handling.
- Added an initialization step in the Load function to register attachment processes, improving the setup for file management.
- Expanded the README to include detailed documentation on the new Process API, outlining available processes, permission models, and usage examples for better developer guidance.
- Added concurrent fetching of runtime status for each robot in the ListRobots function, improving response efficiency.
- Updated the Response struct to include new fields for runtime status: Running, MaxRunning, LastRun, and NextRun, optimizing dashboard display.
- Implemented unit tests to verify the inclusion of runtime status fields in the ListRobots response, ensuring accurate data representation for users.
- Introduced a new `Type` field in the `ActivityQuery` struct to allow filtering activities by type (e.g., execution.started, execution.completed, execution.failed, execution.cancelled).
- Updated the `ListActivities` method in `ExecutionStore` to handle the new type filter, mapping it to corresponding execution statuses.
- Enhanced unit tests in `execution_test.go` to validate filtering by activity type, including tests for valid and invalid type scenarios.
- Modified OpenAPI definitions and related types to support the new type filter in the activities endpoint, improving API usability and flexibility.
- Implemented `ListResults` and `CountResults` methods in `ExecutionStore` to retrieve and count completed executions with delivery content, supporting filtering by member ID, team ID, trigger type, and keyword.
- Developed `ListActivities` method to derive activities from execution status changes, allowing retrieval of recent activities for a team.
- Created corresponding unit tests in `execution_test.go` to validate the functionality of results and activities listing, ensuring accurate filtering and pagination.
- Updated OpenAPI routes and types to include new endpoints for listing results and activities, enhancing the API's capabilities for managing execution data.
- Enhanced the `extractGoalName` function to skip empty lines, markdown headers, and horizontal rules while extracting the first meaningful line as the goal name.
- Implemented a new `stripMarkdownFormatting` function to remove various markdown formatting elements, including bold, italic, inline code, and link syntax.
- Added comprehensive unit tests for both `extractGoalName` and `stripMarkdownFormatting` to ensure correct functionality across various markdown scenarios.
- Added logic to calculate the current state for progress bar display in the `NewExecutionResponseBrief` function.
- If `exec.Current` is nil, the progress is derived from the task statuses, providing a synthetic current state for better UI feedback.
- Updated the `Current` field in the execution response to include this calculated progress, improving clarity in execution status representation.
- Introduced a new `Description` field in the `Task` struct for a human-readable task description, improving UI clarity.
- Updated the `ParseTask` function to save the description from input data and convert it to a message if no explicit messages are provided.
- Enhanced the `Executor` to update UI fields with localized messages during task execution phases, ensuring better user feedback.
- Implemented a new method in the `ExecutionStore` to persist task status updates, allowing real-time UI updates.
- Added unit tests to validate the new task description handling and UI updates during execution phases.
- Refactored failure message construction to use concise phase names instead of full error messages, improving clarity in UI feedback.
- Updated localization support for failure messages, ensuring accurate translations for various phases in both English and Chinese.
- Added unit tests to validate the new failure message format and localization functionality.
- Added `Name` and `CurrentTaskName` fields to the `Execution` struct for improved UI display during execution phases.
- Implemented localization support for UI messages, allowing dynamic updates based on the execution context and user locale.
- Updated the executor to manage these fields at various phases, ensuring accurate representation of execution status.
- Enhanced OpenAPI documentation to reflect the new fields and their usage in execution responses.
- Added unit tests to validate the functionality of UI fields and localization handling.
- Updated the ListRobots function to enhance caching behavior by explicitly requiring the autonomous_mode filter to be true when using cached results.
- Improved comments for clarity on caching conditions and the implications of autonomous_mode filtering.
- Ensured that when autonomous_mode is not specified or set to false, the database is queried to include all robots, maintaining comprehensive results.
- Added a new `Types` field to the `AssistantFilter` struct to allow filtering by multiple types using an IN query.
- Updated the `GetAssistants` function to apply the new multi-type filter alongside the existing single type filter.
- Modified the OpenAPI endpoint to support the new `types` query parameter for better flexibility in assistant retrieval.
- Ensured backward compatibility by setting a default type when neither `type` nor `types` is specified.
- Updated related documentation and tests to reflect the changes in filtering capabilities.
- Added support for a new `RobotPrompt` field in the `Uses` struct to allow for custom robot system prompts.
- Updated the `Load` function to initialize `RobotPrompt` with a default value if not provided.
- Modified the `SystemConfig` struct to include a connector for the new `RobotPrompt` agent.
- Enhanced the asset binding to include new files related to the `robot_prompt` assistant.
- Updated related documentation and tests to reflect the addition of the `RobotPrompt` functionality.
- Removed the job system integration from the robot execution flow, transitioning to a dedicated ExecutionStore for managing execution records.
- Updated the design documentation to reflect the new architecture, emphasizing the relationship between robots and concurrent executions.
- Revised the API to return execution IDs instead of job IDs, ensuring clarity in execution tracking.
- Enhanced logging mechanisms to utilize the kun/log package for better traceability of execution phases.
- Updated tests and documentation to align with the removal of job-related structures and the introduction of execution management.
- Updated the CreateRobot API to auto-generate the member_id if not provided, enhancing usability and ensuring unique identifiers.
- Revised CreateRobotRequest structure to make member_id optional, aligning with the new auto-generation logic.
- Added a new function for generating unique member IDs with collision detection, ensuring compliance with existing ID patterns.
- Enhanced unit tests to validate the new behavior, ensuring robust error handling and proper ID generation.
- Updated related OpenAPI documentation to reflect changes in request structure and behavior.
- Added support for filtering robots by `autonomous_mode` in the ListRobots API.
- Enhanced ListQuery structure to include an optional `AutonomousMode` field.
- Updated listRobotsFromDB function to apply the autonomous mode filter based on the query.
- Created new test cases to validate the filtering functionality for both autonomous and on-demand robots.
- Revised related OpenAPI endpoints and frontend integration to accommodate the new filtering options.
- Revised implementation strategy to emphasize immediate frontend integration after backend phases.
- Detailed tasks for Phase 1-FE, including SDK implementation and page integration for robot management.
- Updated progress tracking table to reflect current status of backend and frontend phases.
- Added verification steps for frontend integration to ensure end-to-end functionality.
- Added `YaoCreatedBy` and `YaoTeamID` fields to `RobotState` and `RobotResponse` for improved access control.
- Updated `GetRobotStatus` to retrieve permission fields from the store and populate the robot state.
- Modified `robotFields` in the store to include new Yao permission fields for better management of access control.
- Enhanced OpenAPI integration by registering robot routes and ensuring proper permission checks in handlers.
- Updated documentation in TODO.md to reflect the completion of permission logic and API enhancements.
- Added a `Bio` field to the `Robot` structure, allowing for a description of the robot.
- Updated the `cleanupAPITestRobots` function to delete robots with member IDs starting with both "robot_api_" and "api_robot_".
- Implemented new API functions for creating, updating, and removing robots, ensuring proper validation and cache management.
- Enhanced request and response types in `api/types.go` to include the new `Bio` field.
- Added comprehensive tests for the new CRUD operations in `robot_test.go`, ensuring robust validation and error handling.
- Introduced a new `RobotStore` in `store/robot.go` for core CRUD operations on robot members, including methods for saving, retrieving, listing, deleting, and updating configurations.
- Extended the API layer with new thin wrappers in `api/robot.go` for creating, updating, and removing robot members, ensuring cache refresh and validation.
- Added new files `api/results.go` and `api/activities.go` to handle results and activities, respectively, integrating with the execution store for enhanced functionality.
- Updated `DESIGN.md` and `GAPS.md` to reflect the new architecture and decisions regarding the separation of store and API layers, promoting better organization and reuse across different consumers.
- Updated the `TestE2EControlStop` function to improve execution status verification with a retry mechanism, accommodating potential delays.
- Streamlined `TestE2EEventTriggerVariousEventTypes` to focus on a single event type, reducing CI execution time while maintaining coverage.
- Enhanced logging and assertions for better clarity in test outcomes, improving overall test reliability.
- Enhanced the `TestE2EControlStop` function to implement a retry mechanism for verifying execution status, allowing for a longer wait time and accommodating potential delays in execution completion.
- Simplified the `TestE2EEventTriggerVariousEventTypes` by focusing on a single representative event type to reduce CI execution time, while maintaining coverage of event handling logic.
- Updated logging and assertions to reflect the new execution state checks, ensuring clarity in test outcomes and improving overall test reliability.
- Introduced a new `unit-test-robot-e2e` target in the Makefile to run end-to-end tests for the robot API, requiring real LLM calls and specific environment setup.
- Updated the `pr-test.yml` and `unit-test.yml` workflows to include a dedicated job for Robot E2E Tests, ensuring proper execution in CI with necessary services and dependencies.
- Enhanced the TODO.md to reflect the completion of various E2E test flows, marking them as done and outlining future integration with OpenAPI.
- Refactored context handling in several test files to utilize `context.Background()` for improved clarity and consistency in execution context.
- Updated the API documentation in TODO.md to reflect the completion of the Go API implementation and end-to-end tests for the main flow (P0 → P1 → P2 → P3 → P4).
- Clarified that Process handlers and JSAPI are optional features, moving them to Phase 12, while emphasizing that the Go API is sufficient for MVP integration.
- Removed obsolete API files (`api.go`, `jsapi.go`, `process.go`) as they were stubs and not implemented in Phase 10, streamlining the codebase.
- Revised the structure of the TODO.md to better outline the goals and tasks for Phases 11 and 12, ensuring clear tracking of progress and dependencies.
- Added `robot_email` field to the Robot structure for specifying the sender's email address in email communications.
- Updated the EmailTarget structure by removing the CC field, simplifying the configuration for email targets.
- Revised TECHNICAL.md to include details on the new `robot_email` field and its usage in email delivery, ensuring clarity on the sender identity.
- Enhanced the Delivery Center's email handling to utilize the Robot's email as the From address, with a fallback to the provider's default if not configured.
- Updated DESIGN.md to reflect changes in email delivery architecture and added new sections for global email configuration.
- Marked completion of related tasks in TODO.md, confirming the integration of new email features and structures.
- Modified the DeliveryResult structure across multiple executors to include RequestID and Content fields, providing detailed summaries and bodies for dry-run, sandbox, and standard deliveries.
- Updated related test cases to reflect changes in the DeliveryResult structure, ensuring accurate validation of delivery types and content handling.
- Revised input formatting to display delivery summaries instead of types, improving clarity in execution summaries.
- Updated the DeliveryResult and ChannelResult structures to include new fields such as RequestID, SentAt, and improved content handling.
- Revised EmailTarget and WebhookTarget structures to clarify their configurations, including the addition of Template and Method fields.
- Enhanced the DeliveryPreferences structure to support Email, Webhook, and Process configurations, improving the flexibility of delivery options.
- Updated DESIGN.md and TECHNICAL.md to reflect these changes, ensuring comprehensive documentation of the new delivery architecture.
- Marked the completion of related tasks in TODO.md, confirming the integration of new features and structures.
- Enhanced the `mailer` provider to support email attachments, including both regular and inline attachments.
- Updated the `buildMessage` method to handle multipart email formats for messages with attachments.
- Added new tests for attachment handling in `mailer_test.go` and `mailgun_test.go`, ensuring comprehensive coverage for single, multiple, and inline attachments.
- Revised `TODO.md` to reflect the completion of attachment support across email providers, confirming that all major providers now support this feature.
- Removed RobotID from ExecutionRecord and DeliveryContext structures, emphasizing the use of MemberID as the globally unique identifier.
- Updated relevant documentation in DESIGN.md, TECHNICAL.md, and TODO.md to reflect these changes, ensuring clarity on the new context handling.
- Revised methods in ExecutionStore and Executor to align with the updated model, enhancing data management and execution tracking.
- Improved test cases to validate the new structure and ensure comprehensive coverage of execution scenarios.
- Updated the ExecutionRecord structure in TECHNICAL.md to include new fields such as ExecutionID and improved status tracking with cancellation support.
- Revised the ExecutionStore implementation in store/execution.go to add methods for updating execution status and current state, as well as deleting records.
- Marked the completion of the execution record model in TODO.md, reflecting the integration of new features and ensuring comprehensive tracking of execution history.
- Updated bindata.go and model.go to include the new execution model, enhancing the overall architecture for better data management.
- Revised DESIGN.md to update the DeliveryRequest structure, replacing exec_id with member_id and adding context for execution_id and trigger.
- Expanded TECHNICAL.md to clarify the DeliveryContext structure, including detailed comments on RobotID and MemberID for better understanding of their roles.
- Updated TODO.md to reflect changes in the execution record model, ensuring accurate tracking of the new fields and their implications for delivery processes.
- Enhanced documentation to improve clarity on the updated context and execution tracking, facilitating better developer understanding and implementation.
- Revised DESIGN.md to incorporate support for multiple delivery targets across email, webhook, and process channels, enhancing the flexibility of the delivery system.
- Expanded TECHNICAL.md with detailed descriptions of the new DeliveryPreferences structure, including EmailPreference, WebhookPreference, and ProcessPreference, to clarify their configurations and usage.
- Updated TODO.md to reflect the integration of multiple targets in delivery preferences, ensuring comprehensive tracking of the ongoing enhancements in the delivery architecture.
- Enhanced documentation to outline the new delivery channels and their configurations, improving clarity and usability for developers and users.
- Revised DESIGN.md to clarify the architecture of the P4 delivery process, emphasizing the separation of content generation and channel decision-making.
- Expanded TECHNICAL.md with detailed notes on the DeliveryRequest structure, DeliveryContent generation, and the role of the Delivery Center in managing delivery channels.
- Updated TODO.md to reflect the completion of the Delivery Agent setup and the integration of delivery preferences, ensuring comprehensive tracking of the P4 implementation progress.
- Enhanced documentation to outline the new delivery channels and their configurations, including email and webhook options, for improved clarity and usability.
- Marked the P3 Run Implementation as complete in TODO.md, reflecting the successful integration of task execution and validation.
- Updated the status of tests related to the ContinueOnFailure option, indicating their completion with detailed test cases for various execution scenarios.
- Enhanced run_test.go with new tests to validate the behavior of task execution under different ContinueOnFailure configurations, ensuring robust error handling and task management.
- Revised the RunExecution method to accept configuration data, improving flexibility in execution parameters.
- Revised DESIGN.md to clarify the architecture of the P3 entry point, including updated RunConfig parameters and task execution flow.
- Expanded TECHNICAL.md with detailed implementation notes on multi-turn conversation flow, validation rules format, task dependencies, and resource management.
- Removed outdated architecture diagrams from TODO.md and added comprehensive notes on the new multi-turn conversation handling and validation mechanisms.
- Documented the functionality of the new `yao/assert` package and its integration into the validation process.
