v0.1.24

0.1.23 published four platform packages and not the CLI, so the version is burned. Nothing referenced it: the CLI never published, and the platform packages are not meant to be depended on directly.

lock the new version too

Cargo.toml moved to 0.1.23 and the lock did not, so every build failed with --locked refusing to update it.

v0.1.23

First release under @cqxai. The bin is still cqx and the install line people have in their notes still works; only the scope moved.

the CLI publishes as @cqxai/cli

The bare name cqx on npm belongs to somebody else entirely and always did, so scoping was never a choice. What changes is only the scope: the bin is still cqx, and npm i -g @cqxai/cli still gives you the command you typed before.

Four platform packages carry the executables as optional dependencies with os and cpu set, so a machine fetches the one binary it can run rather than all four.

Move npm CLI and platform packages to @cqxai

Merge pull request #49 from samifouad/claude/mcp-session

expose the MCP dispatch, so stdio is not the only way in

expose the MCP dispatch, so stdio is not the only way in

cqx mcp reads lines from stdin, and that is one transport rather than the only one. The desktop application wants to serve the same tools over HTTP on a port — so that an agent talks to the process that already has the tree warm instead of starting a fresh one for every question, and so that configuring an agent writes a URL rather than hunting for a binary on PATH.

What it must not be is a second implementation. An HTTP caller that answered tools/list from its own table would drift from this one, and the drift would show up as an agent that can see a tool it cannot call.

So Session is public, with new and handle(line) -> Option<String>, and the stdio loop uses the same type it always did. None still means the message was a notification: stdio writes nothing, and an HTTP caller answers 202 with no body.

The test is the door rather than the room — it goes through the exported type and counts five tools, because the way this breaks is somebody writing the second table.

Merge pull request #48 from samifouad/claude/propose-from

let a caller bring its own idea of what is in force

let a caller bring its own idea of what is in force

propose works out the current configuration by resolving the repository, which is right for the CLI and wrong for the desktop application. There, rules can come from ~/.config/cqx/rules.json when a repository has no cqx.json of its own — so "what is in force" is not something resolve can work out from the repository alone.

The second half matters more. When that application writes a repository's first cqx.json, the file has to be seeded from what was in force. Write one field into an empty document and every other setting silently falls back to a default: the change reports as one tightening while actually being several loosenings, and the ratchet would have approved it.

So propose_from takes the document and the configuration it produces, and propose becomes the two-line version that resolves them itself. Same classification, same writer, one more caller that cannot disagree with the others.

The test is the case itself: two rules already stricter than the defaults, coming from somewhere the repository cannot see. Seeded, one change is one change and the other two survive into the file. Unseeded, the document really does drop them.

Merge pull request #47 from samifouad/claude/propose-rule

propose_rule: an agent can raise the standard and cannot lower it