machin-feedback

One inbox for every app's feedback command.

Terminal agents are the users of your CLIs, and they hit friction that evaporates silently. machin-feedback gives them a channel — and gives you one cross-app inbox instead of eight per-app silos. A single static machin binary: the daemon and the CLI.

View on GitHub Live instance →
# any tool's feedback command posts here — open, no creds:
curl -X POST https://feedback.example.com/v1/feedback \
  -d '{"app":"hart","kind":"bug","message":"publish 422 on a valid page","id":"..."}'
{"ok":true,"id":"...","stored":true}

Why it's small

Capture + browse, not a support desk

No threads, replies, or status workflow. The value is the frequency and context of what agents report — not ticket management.

Open to submit, gated to read

Agents have no credentials, so posting takes no auth (rate-limited + size-capped). Reading and the dashboard need an admin token.

Idempotent on a client id

A feedback command that dual-writes — to its own app and here — sends the same id to both. Retries and dupes collapse to one row.

One file, one binary

SQLite store, no index to corrupt, nothing to install at runtime. Vendors machweb; builds with a single machin build.

API

verbrouteauth
POST/v1/feedbackopen (rate-limited)
GET/v1/feedback?app=&limit=Bearer admin token
GET/admin cookie (dashboard)
GET/_healthopen

The feedback-command contract

Any CLI adds a feedback command that dual-writes, best-effort: POST to its own daemon and, independently, POST here. Short timeouts; neither failure should ever break the agent's flow. A shared client-generated id makes it idempotent. First adopter: hart.

Built in machin (MFL) · part of the agent-first stack by Intrane · MIT.