Files
dirigate/examples/basic.yaml
T
g4borg c62d8daea8 chore: rename packages/ to crates/
Move all 29 workspace members from packages/<name>/ to crates/<name>/.
Updates: workspace Cargo.toml (members + path deps), justfile, root
CLAUDE.md, scripts/build/CARGO_INSTALL.md, docs/architecture/crates.md
(renamed from packages.md), structural references in docs/architecture
and docs/configuration, per-crate CLAUDE.md self-references. Historical
plans, reports, and building/ docs are left untouched.

No behavior change; just check-all stays green and fermata tests pass.
2026-04-30 21:58:57 +02:00

250 lines
8.1 KiB
YAML

# 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