feat(context): load and execute context hooks

[hayemaxi]

RFC: #1050

This PR begins implements the required logic for executing hooks. This PR has pending follow ups to handle the remaining items. Note that the logic is currently inaccessible from a normal chat session.

It implements:

• "Hooks", which are defined in the context json files. They are loaded along with the normal context.
  • "conversation_start" hooks that run once and are attached to the top of the context,
  • "per_prompt" hooks that run each time there is a prompt, and are attached to the user prompt.
• Start with 1 hook type, "inline hooks", which simple execute a bash command.
• A HookExecutor to asynchronously call hooks in order from the configs.
• Logic to add/remove/enable/disable hooks via commands
• A cache to hold recent executions of hooks to avoid calling them too much.
  • "conversation_start" hooks are held in cache indefinitely. "per_prompt" hooks can have
• The bash execution logic from exceute_bash tool was moved to a helper function so that it can be re-used here.

Remaining items in another PR:

• Call the hooks during a chat session and attach them to context appropriately
• Commands to enable, disable, add, and show hooks
• Add Criticality as according to the spec
• Handle user having multiple hooks with the same name (enforce uniqueness)
• Tests

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 2.36486% with 289 lines in your changes missing coverage. Please review.

Project coverage is 13.96%. Comparing base (bcd0c0b) to head (edaf69d).
Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/q_cli/src/cli/chat/hooks.rs	3.96%	121 Missing ⚠️
crates/q_cli/src/cli/chat/context.rs	2.29%	85 Missing ⚠️
crates/q_cli/src/cli/chat/tools/execute_bash.rs	0.00%	83 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1176      +/-   ##
==========================================
+ Coverage   13.94%   13.96%   +0.01%     
==========================================
  Files        2363     2365       +2     
  Lines      204483   204847     +364     
  Branches   184847   185211     +364     
==========================================
+ Hits        28520    28604      +84     
- Misses     174562   174837     +275     
- Partials     1401     1406       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brandonskiser]

TIL about r#

[brandonskiser]

Reason why we need to force namespacing concerns on the user rather than handle it ourselves? Like a hook id could be global/{name} / {profile_name}/{name} if multiple {name} hooks exist

[hayemaxi]

This is the same issue, what if the user tries to add 2 {name} hooks to global? Instead of throwing an errors, we can rename hooks with duplicate names as they arrive, e.g.

hook add ... "random_number" --global
hook add ... "random_number" --global # again
# ... list hooks
global:
- random_number
- random_number (1)

This also handles the issue of bypassing the duplicate name hook check by writing to the config manually.

[brandonskiser]

oh are you saying that you agree with the profile/hook_name pattern where we want to support hook_name across multiple profiles? e.g.

profile_1:
- hook_1
- hook_2

profile_2:
- hook_1

Then referencing hook_2 is fine, but we'll give an error stating that the user has profile_1/hook_1 and profile_2/hook_1

But, then you're asking about the case where we have multiple hook names tied to the same profile?

So we can either:

• throw an error stating a hook with that name already exists
• or, create a new hook and just call it hook_name_{rand_num}

[hayemaxi]

or, create a new hook and just call it hook_name_{rand_num}

This sounds good to me. Otherwise, I am hesitant to explicitly make a hook id with global/ or profile/ prefix since it is just additional complexity. Duplicate naming across profiles should be acceptable since they are stored in separate config files (and cannot be active at the same time).

Instead I was thinking we can just enforce it this way:

• --global flag (like other context commands) controls for the global config, otherwise the profile config
• names must be unique within a single config file, e.g. within global, or within a single profile.
  • if the user tries to add a non-unique name, add an increasing number on the end
  • if they add one via manually editing config files, fix this on startup by adding an increasing number to it
• 2 execution caches, global and profile. We can clear the profile cache if they switch profiles

[hayemaxi]

Will follow up in a new PR.