>> mq-hal
The problem with giving an AI model access to a terminal is trust. A model that can run arbitrary shell commands is a model that can delete files, overwrite history, and exhaust resources — not through malice, but through misunderstanding. mq-hal is built on the premise that the model should never touch the shell directly.
The architecture is a strict pipeline. You type a prompt in natural language. Ollama runs a local Qwen model and returns a JSON intent. A Python router reads that intent, checks it against an explicit allowlist, and either executes the matched action or refuses. The model does not run commands. It makes proposals. The router decides what is allowed.
Everything runs locally. No API key. No cloud call.
Ollama manages the model on your machine,
and the router enforces the boundary between suggestion and execution.
The session memory is a local .jsonl file.
Nothing leaves the machine.
The command surface covers the things you actually ask about during a working session:
git status across registered repositories, release readiness, CI state,
a structured brief of what changed and what is pending.
mq-hal brief reads your repos and tells you where things stand.
mq-hal release-brief summarises what is ready to ship.
mq-hal audit checks for common problems.
The fix planner is the most deliberate design decision. When HAL identifies a problem, it does not fix it. It prints the commands you would need to run, clearly labelled, for manual review. The model surfaces the repair. You decide whether to apply it. That distinction — between knowing what to do and being authorised to do it — is the whole point.
Session memory gives the router continuity.
mq-hal remember "release looked good" writes a timestamped note.
mq-hal timeline shows the history of actions, briefs, and notes
in chronological order, filterable by type and repo.
It is a lightweight log of intent — not a chat history,
but a record of what was decided and observed.
The integration contract is explicit. mq-hal owns the feature logic. mqlaunch owns the command surface. New commands require tests and documentation before they ship. The boundary between tools is written down, not assumed.
The model returns JSON. The router enforces the allowlist. That separation is what makes the system trustworthy — not because the model is good, but because its reach is bounded.