Array of user actors that will interact with the backend system.
These actors define the different types of authenticated users who will access the system, each with their own permissions and capabilities. The actors specified here directly influence:
Common patterns:
Each actor should have a clear, distinct purpose and non-overlapping responsibilities to ensure clean authorization logic in the generated code.
Timestamp when the event was created.
ISO 8601 formatted date-time string indicating when this event was emitted by the system. This timestamp is crucial for event ordering, performance analysis, and debugging the agent workflow execution timeline.
Format: "YYYY-MM-DDTHH:mm:ss.sssZ" (e.g., "2024-01-15T14:30:45.123Z")
Array of document specifications to be generated in this scenario.
This array defines the planning documents that the Analyze Agent will create during this event. Each document serves a specific purpose in the requirements analysis phase and contributes to the overall system specification.
Requirements:
Typical document progression:
The array structure allows flexible composition of documents based on project complexity and specific needs.
A unique identifier for the event.
OptionallanguageLanguage for document content. When specified by the user, this takes precedence over the locale setting for determining document language.
Function calling trial statistics for the operation.
Records the complete trial history of function calling attempts, tracking total executions, successful completions, consent requests, validation failures, and invalid JSON responses. These metrics reveal the reliability and quality of AI agent autonomous operation with tool usage.
Trial statistics are critical for identifying operations where agents struggle with tool interfaces, generate invalid outputs, or require multiple correction attempts through self-healing spiral loops. High failure rates indicate opportunities for system prompt optimization or tool interface improvements.
Prefix identifier for the analysis scenario.
This prefix serves as a namespace for all documents generated within this scenario, ensuring consistent organization and preventing naming conflicts. It typically represents the project or service name and is used to:
Examples: "e-commerce", "social-media", "banking-system", "logistics-platform"
The prefix should be:
Current step number in the multi-event analysis scenario.
This field tracks the progression through a series of related analyze events, allowing the system to maintain context and ensure proper document sequencing. The step number is crucial for:
Step progression patterns:
The step number should increment with each new event in the same scenario, and agents use this to understand the current phase of analysis.
Detailed token usage metrics for the operation.
Contains comprehensive token consumption data including total usage, input token breakdown with cache hit rates, and output token categorization by generation type (reasoning, predictions). This component-level tracking enables precise cost analysis and identification of operations that benefit most from prompt caching or require optimization.
Token usage directly translates to operational costs, making this metric essential for understanding the financial implications of different operation types and guiding resource allocation decisions.
Unique identifier for the event type.
A literal string that discriminates between different event types in the AutoBE system. This field enables TypeScript's discriminated union feature, allowing type-safe event handling through switch statements or conditional checks.
Examples: "analyzeWrite", "databaseSchema", "interfaceOperation", "testScenario"
Event interface for analyze scenario composition operations in the AutoBE system.
This interface represents an event that orchestrates the creation of multiple analysis documents as part of a comprehensive requirements analysis phase. It enables the Analyze Agent to generate a series of interconnected planning documents that collectively form a complete specification for backend development.
The scenario event follows the waterfall model approach, where each document builds upon previous ones to create a logical flow of information from high-level service overview to detailed technical specifications. This systematic approach ensures that all aspects of the backend system are thoroughly documented before any code generation begins.
Key characteristics:
Typical usage flow:
Author
Kakasoo