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.
This commit is contained in:
@@ -0,0 +1,249 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user