First class support for hooks and plugins for extensibility

Hooks are user-configurable commands that execute automatically at specific trigger points during the application lifecycle.
They provide a way to extend functionality and modify agent behavior through:
- Context manipulation: Only adding context information, no modifying/deleting should be allowed.
- Agent control: Approving/denying tool usage, updating system prompts.
- Workflow integration: Calling MCP tools, validating inputs, or triggering external processes.
- Content processing: Preprocessing prompts, post processing responses, or managing conversation history.

**Key Principles**
- Hooks that inject context should support blocking/synchronous behavior with timeouts.
- Hooks that do not inject context can run Asynchronously.
- Hook failures should be communicated clearly to the user and logged.
- Hooks should support both parallel and sequential execution to minimize latency.
- Hooks should support both synchronous and asynchronous execution.
- Hooks should support a timeout in order to not block the agent if failing.
- Configuration should be simple and flexible.
- Hooks should have access to relevant context about the triggering event.
- Context retention should be configurable - some hooks need persistent context, others should avoid consuming context window.
- Hook actions should be instrumented, and observable to see exactly what hooks are doing to help debug / iterate.

**Technical Implementation Requirements:**

- Configuration Format: Some configuration of hooks will be required by each agent. Examples are listed but will be left up to the tool owners to decide.

_Example Basic Configuration Format_
```
{
"hooks": {
"userPromptSubmit": "python /scripts/enhance_prompt.py",
"sessionStart": "/scripts/load_context.sh",
"stop": "/scripts/save_summary.py",
"enabled": "true"
}
}
```

_Example Advanced Configuration Format_
```
{
"hooks": {
"userPromptSubmit": [
{
"command": "python /scripts/validate_input.py",
"execution": "parallel",
"enabled": "true",
"timeout": 5
},
{
"command": "python /scripts/enhance_context.py",
"execution": "parallel",
"enabled": "true",
"condition": "previous.returnCode == 0"
},
{
"command": "/scripts/log_interaction.sh",
"execution": "non-blocking"
"enabled": "false"
}
],
"sessionStart": {
"command": "/scripts/setup_environment.sh",
"enabled": "true"
},
"stop": [
{
"command": "python /scripts/save_session.py",
"execution": "parallel"
},
{
"command": "/scripts/cleanup.sh"
}
]
},
"hookSettings": {
"defaultTimeout": 5,
"logLevel": "info",
"cached_ttl": 500,
"enabled": "true"
}
}
```

- Hook Input Data: We need to define what data hooks receive about the current scope, following is the recommendation we have -

1. Session ID: current session_id
2. Prompt: current prompt text
3. Context: current context object
4. User State: Available via `context.user` and `context.environment`
5. Context Scope Management: Two distinct context scopes must be supported:
a. User Prompt Context (Global Scope)
Purpose: Context relevant to a user that should be applied to all projects
Storage: some global rules directory
b. Session Context (Workspace Scope)
Purpose: Context that is applicable to only a single project
Storage: workspace or repository specific directory

- Multiple Hook Support:
1. Support multiple hooks for the same trigger.
2. Execution order based on configuration order.
3. Ability to conditionally execute hooks.

- Execution Model:
_Synchronous vs Asynchronous_
1. By default, hooks that modify the context will execute synchronously (blocking).
2. Async hooks should not block main execution flow.
3. A Timeout should be added for blocking hooks as to not prevent the entire agent from hanging if an error occurs in the hook

_Advisory Control and Response Structure_
Hook system should support advisory control mechanisms that can return both detailed data and summary information.
a. Detailed blob data: Complete information payload for programmatic consumption.
b. Summary text : Human-readable condensed view of the results. Example summary format: "Found 2 related entities in knowledge base - [x, y]"

_Error Handling_
1. Hook failures should be logged but not crash the main application.
2. Support for "critical" hooks that can block execution on failure.
3. Clear error messages when hooks fail.
4. Timeout mechanism for long-running hooks.

_Telemetry and Observability_
1. Hook actions should be instrumented with logging and metrics.
2. System must provide visibility into hook execution flow for debugging.

_Security Considerations_
1. Hooks run with the same permissions as the main application.
2. Input sanitization for hook commands

- Toggle support: Users should be able to disable their hooks with a simple boolean rather than needing to delete their entire config.

- Typical Hook Execution Flow
_Pre-execution Phase:_
1. Load hook configuration.
2. Set up environment variables.
3. Validate hook commands.
4. Execute pre-hooks in order

_Main Execution Phase_
1. Execute the main tool/command.
2. Capture results and errors.
3. Update context variables.

_Post-execution Phase_
1. Execute post-hooks with results.
2. Handle any hook failures.
3. Clean up temporary resources.
4. Log execution summary.

- Success Criteria
1. Functionality: All hook types work as specified with proper context and behavior control.
2. Performance: Hook execution adds minimal overhead (<100ms for simple hooks, parallel execution reduces latency).
3. Flexibility: Hooks can modify agent behavior beyond just adding context (approval/denial, user interaction, system prompt updates).
4. Context Management: Configurable retention policies prevent unnecessary context window consumption.
5. Reliability: Hook failures don't crash the main application.
6. Security: No security vulnerabilities through hook execution.
7. Usability: Configuration is simple and well-documented despite increased flexibility.
8. Extensibility: Easy to add new hook types, behaviors, and modify existing ones