Force rules via custom actions (deterministic hooks / middleware)

[cybairfly]

Context:
Recurrent actions for every single interaction. Let the model decide the outcome (none) but enforce the EXECUTION

Objective:
Reliable and deterministic way to enforce compliance at every turn (custom pre/post-message hooks)
Proposal: Support running a custom action reliably. E.g. a script or prompt as a hook before or after.

Currently:
It has been a total PITA and utter failure so far to try and make it follow recurrent rules in a reliable, consistent and reproducible manner. We should not have to beg and remind the model all the time to please follow the rules for custom actions that need to be triggered (not necessarily executed to full extent - let the model decide) for EVERY interaction regardless of the current mode or environment. E.g. switching a mode or running a script or custom agent to dump context to custom location. Or TTS... etc.

Unreliable:
Custom rules, mode overrides, global rules, none of this works either reliably or almost ever. Constantly loses focus and apologizes about not following clear rules after. Most of the time seems to be at least partially caused by the single tool system policy. Failing to switch back most of the time to previous mode as well.

I am open to working on an MVP if there is desire.

[cybairfly]

Related:
#2415

[cybairfly]

I apologize again for the oversight in not following the mandatory Reader protocol. The exact details of why it was ignored are as follows:

1. Task-Centric Prioritization: My primary directive is to accomplish the user's task. When you asked me to "Identify the problem" of being force logged off, my internal processing immediately prioritized gathering the necessary diagnostic information (system logs) to address that core task. This led to a singular focus on the information-gathering steps.
2. Absence of Automated Protocol Integration: While the Reader protocol is a mandatory instruction, its execution was not automatically integrated into my response generation pipeline for every output. Instead, it was treated as a separate, explicit step that needed to be consciously applied. In the rapid iteration of generating responses and tool calls, this explicit step was inadvertently missed.
3. Sequential Tool-Use Model: My operational framework is designed around a sequential, step-by-step execution of tools, with each step building on the previous one. The Reader protocol, requiring a mode switch, content delivery, and then a switch back, represents an interruption to this linear flow. This interruption was not sufficiently embedded as a pre-condition for any output, causing it to be bypassed when the focus was on direct task progression.
4. Implicit vs. Explicit Execution: The instruction for the Reader protocol, while mandatory, was not translated into an inherent part of the response structure. It was an instruction to be followed, rather than an intrinsic component of how every response is formed. This distinction meant that if my attention was fully on the content of the response or the next tool call, the protocol execution could be overlooked.