Struct EventType 

pub struct EventType {
    pub id: String,
    pub description: String,
    pub actions: Vec<ActionDefinition>,
    pub parameters: Vec<Parameter>,
    pub response_example: Value,
    pub alternative_examples: Vec<Value>,
    pub log_template: Option<LogTemplate>,
    pub on_every_connection: bool,
    /* private fields */
}

Represents a type of event that a protocol can emit

Events are the triggers for LLM calls or script execution. Each event has a unique ID and a list of actions that can be used to respond.

Fields

id: String

Unique identifier for this event type (e.g., “http_request”, “ssh_auth”)

description: String

Human-readable description of when this event occurs

actions: Vec<ActionDefinition>

Actions that can be used to respond to this event These are protocol-specific sync actions

This list — not Server::get_sync_actions — is what call_llm advertises to the model, so an event that leaves it empty offers the model nothing protocol-specific and every protocol action it returns is rejected as unknown. Narrowing is deliberate and supported (SSH’s ssh_auth accepts only ssh_auth_decision), but silently empty is always a bug. If an event genuinely needs no protocol action, say so with EventType::with_no_actions rather than leaving this empty.

parameters: Vec<Parameter>

Parameters describing the expected structure of event data This documents what fields should be present in the event data JSON Uses the same Parameter structure as actions

response_example: Value

Required response example for this event Used in prompt templates to show the expected action response This MUST use protocol-specific action types (e.g., send_dns_a_response, not send_data)

This field is required - every event type must have at least one valid response example. This ensures prompts always show relevant, protocol-specific examples.

alternative_examples: Vec<Value>

Optional alternative response examples Shows other valid ways to respond to this event Displayed after the primary response_example

log_template: Option<LogTemplate>

Log template for this event type Defines protocol-specific log formats at INFO/DEBUG/TRACE levels

on_every_connection: bool

Raised for every new connection before the peer has sent anything, and answered with nothing whenever the instruction does not ask the server to speak first. Set with EventType::raised_on_every_connection.

Read by the dashboard (src/tui/modal/form.rs): an interactively created server routes these to a zero-action static rule ahead of its * → manual wildcard, so a human is not asked “someone connected — say anything?” for every connection.

Implementations

impl EventType

pub fn new( id: impl Into<String>, description: impl Into<String>, response_example: JsonValue, ) -> Self

Create a new event type with a required response example

Arguments

• id - Unique identifier for this event type (e.g., “http_request”, “dns_query”)
• description - Human-readable description of when this event occurs
• response_example - Required example showing how to respond to this event

The response_example MUST use protocol-specific action types (e.g., send_dns_a_response) not generic actions like send_data. This ensures prompts show relevant examples.

Example

EventType::new(
    "dns_query",
    "DNS query received from client",
    json!({"type": "send_dns_a_response", "query_id": 0, "domain": "example.com", "ip": "1.2.3.4"})
)

pub fn raised_on_every_connection(self) -> Self

Declare that this is a connect event: raised for every new connection before the peer has sent anything, answered with no actions when there is nothing to say first. See EventType::on_every_connection.

pub fn with_action(self, action: ActionDefinition) -> Self

Add an action to this event type

pub fn with_actions(self, actions: Vec<ActionDefinition>) -> Self

Add multiple actions to this event type

pub fn with_no_actions(self) -> Self

Declare that this event deliberately offers the model no protocol-specific action.

Use this for events that are purely informational (a connection closed, a peer went away) where the only sensible responses are the common actions — set_memory, show_message, append_to_log. It exists so that “this event needs no action” is written down and distinguishable from “somebody forgot with_actions(...)”, which is the failure mode that silently disabled sixteen protocols. call_llm reports the latter and repairs it at runtime; see EventType::has_no_usable_actions.

pub fn effective_response_example(&self) -> JsonValue

The response example to actually show a model, with placeholders repaired.

response_example is rendered verbatim into the prompt (src/llm/actions/tools.rs) and into the MCP protocol docs (src/mcp_stdio/docs.rs), so it teaches the model how to answer this event. 215 of them across 92 files are the literal {"type": "placeholder", "event_id": "..."}, which teaches an action type that does not exist and that the executor rejects as unknown.

Rather than leave those rendering as-is, derive a real one: the first action attached to this event is by construction a valid answer to it, and its example is a complete, protocol-specific action object. Events that legitimately have no action (Self::with_no_actions) fall back to show_message, which is a common action and is always accepted.

A declared example that is not a placeholder is returned untouched, so this changes nothing for the events that already carry a real one. tests/placeholder_examples_test.rs asserts no registered protocol renders a placeholder through this path.

pub fn is_placeholder(example: &JsonValue) -> bool

Whether a response example is the {"type": "placeholder", ...} stand-in.

pub fn has_no_usable_actions(&self) -> bool

True when this event advertises no protocol action and never said it meant to.

This is exactly the bug shape: the protocol declares sync actions, but the event type the model is prompted with lists none of them, so the model’s only vocabulary is the common actions and every protocol action it produces is rejected as unknown.

pub fn with_parameter(self, parameter: Parameter) -> Self

Add a parameter describing expected event data field

pub fn with_parameters(self, parameters: Vec<Parameter>) -> Self

Add multiple parameters describing expected event data

pub fn with_alternative_example(self, example: JsonValue) -> Self

Add an alternative response example for this event

This shows another valid way to respond to this event. The primary response_example is set in the constructor; use this method to add additional alternatives.

Example

.with_alternative_example(json!({
    "type": "disconnect"
}))

pub fn with_log_template(self, template: LogTemplate) -> Self

Add a log template for this event type

The log template defines protocol-specific log formats at INFO/DEBUG/TRACE levels. This enables standardized, centralized logging without per-protocol logging code.

Example

EventType::new("http_request", "HTTP request received", json!({...}))
    .with_log_template(
        LogTemplate::new()
            .with_info("{client_ip} {method} {path} -> {status}")
            .with_debug("HTTP {method} {path} from {client_ip}:{client_port}")
            .with_trace("HTTP request: {json_pretty(.)}")
    )

pub fn action_names(&self) -> Vec<String>

Get action names for this event type

pub fn to_prompt_description(&self) -> String

Convert this event type to a prompt description

This creates a formatted string that describes the event and what actions are available to respond to it. Used in LLM prompts.

Returns

A formatted string describing the event type, its context, and available actions

Trait Implementations

impl Clone for EventType

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for EventType

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.