Motir

The CLI currently tells the world it is "an MCP client of the Motir server" — on the npm package page, in its README and in docs/cli.md. After this story that is false, and it is false in a way that matters commercially: the epic's whole argument is that the CLI is an ordinary consumer of the same public API a third party gets, and the package description is where a prospective user reads what the tool is.

Audience: someone deciding whether to install the CLI, and someone who has installed it and hit a wall. Home: the three places the claim currently lives, plus one new section.

What to write

1. packages/cli/package.json#description — the npm listing's one line. It is a client of Motir's public REST API; it is not an agent-protocol client.
2. packages/cli/README.md — the same correction wherever the protocol is named, plus any architecture note describing the transport.
3. docs/cli.md — the user-facing manual. Correct every place it describes the CLI as MCP-based, and check § Authenticate, § Scopes and § Troubleshooting specifically: the token is now used as an ordinary bearer against /api/v1, so scope refusals surface as a 403 naming the missing scope rather than as a tool error, and that is the wording a stuck user reads.
4. A NEW § on version skew — the CLI is published to npm independently of the server, so a user can hold a CLI newer than the Motir they point it at. Say what the upgrade message means, that it compares the API CONTRACT version and not an app release number, and what to do about it (upgrade the server, or install a CLI matching it). This is the only genuinely new thing a user has to know, and without it the message reads as a bug.
5. A link to the API reference and the spec URL, so a reader who wants to script something themselves knows the CLI is not privileged — which is the claim the whole epic is making, stated where someone will see it.

Scope BOUNDARY

Ends at these four documents. It does NOT change code, tests, help text or any command output — --help strings are product copy owned by the commands, and none of them names the transport. It does NOT document /api/v1 itself; the API reference is 11.4's and renders from the spec. It does NOT rewrite the install, login or agent-wiring sections beyond the protocol claims they contain. It does NOT bump the version or write a changelog entry (11.5.10).

Acceptance criteria

• No document under packages/cli/ or docs/cli.md describes the CLI as an MCP client or names @modelcontextprotocol/sdk — asserted by a grep in the card's own evidence, since these strings are exactly the ones that survive a careless edit.
• package.json#description reads as a public-REST-API client and fits npm's one-line listing.
• docs/cli.md § Authenticate, § Scopes and § Troubleshooting describe bearer-PAT behaviour against /api/v1, including what a 403 for a missing scope looks like and how to mint a token with it.
• A § on version skew exists, states that the comparison is against the API contract version rather than an app release, and gives the two remedies.
• The API reference and the public spec URL are linked, framed as the same API this CLI uses.
• Every code example still runs against the shipped commands and flags — no example invents an option.

Context refs

• packages/cli/package.json — the description field, and where the SDK dependency was.
• packages/cli/README.md · docs/cli.md — the two prose homes; docs/cli.md's § Authenticate was last rebuilt around motir login, so read it before editing.
• docs/decisions/public-api-conventions.md Amendment 4 Q6 — what info.version means, which the skew section must state correctly.
• app/api/openapi/v1.json/route.ts — the public spec URL to link.
• Predecessor: 11.5.6 — the card that makes these sentences false.
• Story: 11.5.