# Basic Example Fixture for dirigent_acp_mocker # # This fixture demonstrates the core features of the ACP mocker: # - Multiple sessions with different scenarios # - Keyword-based response routing # - Random response selection # - Streaming configuration # # Usage: # dirigent-acp-mocker serve --fixtures ./examples/basic.yaml # dirigent-acp-mocker validate ./examples/basic.yaml # dirigent-acp-mocker print ./examples/basic.yaml version: "0.1" # ============================================================================ # Sessions # ============================================================================ # # Define mock sessions that clients can load or use as templates. # Each session represents a conversation with a specific set of messages # and participants. sessions: # ------------------------------------------------------------------------ # Session 1: Simple Greeting # ------------------------------------------------------------------------ # A basic session demonstrating a simple conversation flow. # This can be loaded by clients to test basic chat functionality. - id: "greeting-session" title: "Simple Greeting" created_at: "2025-01-10T10:00:00Z" # Participants in this session participants: - id: "user-1" kind: "user" display_name: "Test User" - id: "assistant-1" kind: "assistant" display_name: "Mock Agent" # Message history for this session messages: - id: "msg-1" session_id: "greeting-session" role: "user" content: "Hello!" created_at: "2025-01-10T10:00:01Z" parent_id: null metadata: null - id: "msg-2" session_id: "greeting-session" role: "assistant" content: "Hello! Welcome to the ACP mock agent. How can I help you today?" created_at: "2025-01-10T10:00:02Z" parent_id: "msg-1" metadata: null # ------------------------------------------------------------------------ # Session 2: Code Assistance # ------------------------------------------------------------------------ # A session demonstrating code-related interactions. # Shows multi-turn conversation with technical content. - id: "code-session" title: "Code Assistance" created_at: "2025-01-10T11:00:00Z" participants: - id: "developer-1" kind: "user" display_name: "Developer" - id: "coding-assistant" kind: "assistant" display_name: "Coding Assistant" messages: - id: "code-msg-1" session_id: "code-session" role: "user" content: "Can you help me write a Rust function to calculate fibonacci numbers?" created_at: "2025-01-10T11:00:01Z" parent_id: null metadata: null - id: "code-msg-2" session_id: "code-session" role: "assistant" content: | Sure! Here's a recursive Rust function to calculate Fibonacci numbers: ```rust fn fibonacci(n: u32) -> u64 { match n { 0 => 0, 1 => 1, _ => fibonacci(n - 1) + fibonacci(n - 2), } } ``` This is the classic recursive approach. For better performance with larger numbers, consider using dynamic programming or an iterative approach. created_at: "2025-01-10T11:00:05Z" parent_id: "code-msg-1" metadata: null - id: "code-msg-3" session_id: "code-session" role: "user" content: "Can you show me the iterative version?" created_at: "2025-01-10T11:00:10Z" parent_id: "code-msg-2" metadata: null - id: "code-msg-4" session_id: "code-session" role: "assistant" content: | Here's an iterative version that's much more efficient: ```rust fn fibonacci_iterative(n: u32) -> u64 { if n == 0 { return 0; } let mut prev = 0; let mut curr = 1; for _ in 1..n { let next = prev + curr; prev = curr; curr = next; } curr } ``` This has O(n) time complexity and O(1) space complexity, much better than the exponential recursive version! created_at: "2025-01-10T11:00:15Z" parent_id: "code-msg-3" metadata: null # ------------------------------------------------------------------------ # Session 3: Empty Template # ------------------------------------------------------------------------ # An empty session that can be used as a template for new conversations. # Useful for testing session creation functionality. - id: "empty-template" title: "Empty Template" created_at: "2025-01-10T12:00:00Z" participants: - id: "default-user" kind: "user" display_name: "User" - id: "default-assistant" kind: "assistant" display_name: "Assistant" messages: [] # ============================================================================ # Responders # ============================================================================ # # Configure how the mock agent generates responses to user prompts. # The responder system uses a simple keyword mapping where specific keywords # in user input trigger predefined responses. responders: # Default strategy for messages that don't match any keyword # Options: "echo", "fixture_only", "random" default_strategy: "echo" # Keyword-based response mapping # When user input contains a keyword, the corresponding response is returned. # This is a simple string-to-string mapping. keyword_map: # If the user mentions "help" "help": "I'm here to help! You can ask me about anything." # If the user asks about weather "weather": "The weather is sunny with a chance of mock responses!" # If the user mentions "code" or "programming" "code": "I can help with code! What language are you working with?" # If the user says hello "hello": "Hello! Welcome to the ACP mock agent. How can I help you today?" # Special keyword for goodbye messages "bye": "Goodbye! Thanks for testing with the ACP mocker." # Testing keywords "test": "This is a test response from the mock agent." # Status check "status": "The mock agent is running normally. All systems operational!" # Random responder configuration # Used when the default_strategy is set to "random" random: # Random seed for reproducibility (use same seed for consistent results) seed: 42 # Corpus of possible responses corpus: - "That's an interesting point!" - "I see what you mean." - "Let me think about that for a moment..." - "Good question! Here's what I think..." - "I understand your concern." - "That makes sense." - "Let's explore that idea further." - "I appreciate you bringing that up." # ============================================================================ # Streaming Configuration # ============================================================================ # # Configure how responses are streamed to clients via Server-Sent Events. # Streaming simulates token-by-token generation like real LLMs. streaming: # Enable or disable streaming enabled: true # Number of tokens (words) to send in each chunk # Smaller values = more frequent updates, more realistic streaming # Larger values = fewer updates, faster overall response tokens_per_chunk: 3 # Milliseconds to wait between chunks # Simulates the generation time of a real LLM # Lower values = faster streaming, higher values = more realistic delays chunk_interval_ms: 80 # Random jitter to add to chunk intervals (milliseconds) # Adds natural variation to timing, making it more realistic # Set to null or 0 to disable jitter jitter_ms: 20