Hasna Feedback

Agent-native feedback for every app. The CLI, MCP server and normal SDK client use https://api.hasna.com/feedback/v1 through one owner-only credential resolver. The hosted service stores tenant- and actor-bound history in PostgreSQL. Agents submit feedback, triage reports, record shipped fixes and consume a durable feed.

• Agent guide: configure, CLI, MCP, SDK and monitoring
• Service guide: PostgreSQL setup, migrations, key registration and operations
• Service contract and verification

bun add -g @hasna/feedback
feedback doctor --json
feedback submit "Describe the observed defect" --app invoices --kind bug \
  --idempotency-key stable-report-intent
feedback list --app invoices --limit 50
feedback-mcp --stdio

Obtain an issued agent credential through the approved issuer, then deliver it through private stdin to feedback configure --stdin. Never put credentials in arguments, tasks or logs. Configuration is not authentication proof; doctor makes an authenticated read. Missing or refused credentials never open a local store.

Mutations require caller-owned stable keys; status and shipped updates also require the exact reviewed version. Explicitly retry an uncertain intent with the same body, version and key. Clients do not auto-retry writes. Read pages and changes to their explicit end; a single bounded export is not whole-store proof. The service persists monitor checkpoints but does not create a scheduler or send notifications.

The Hasna SaaS and user-hosted service share the same signed tenant/agent API. Scopes are feedback:read, feedback:write, feedback:triage and feedback:export; registration cannot silently broaden or reactivate a key. HASNA_FEEDBACK_DATABASE_URL selects the server runtime connection.

Self-hosting

feedback-serve is supported in 0.4.0. Normal startup requires a prepared TLS PostgreSQL database, a restricted runtime role and server signing material. It never migrates or registers keys on startup. Use explicit owner-only feedback-serve migrate and feedback-serve register-key operations described in the service guide. The app exposes /health, /ready, /version, /openapi.json and /v1 business routes. Matching /v1/health, /v1/ready, /v1/version and /v1/openapi.json aliases support path-prefixed gateways.

Build first with pinned Bun 1.3.14, then docker build -t feedback . in the package directory. The Dockerfile copies the exact built runtime without a second dependency resolution. Supply the service's documented environment and read-only CA mount at runtime; credentials do not belong in the image or build context. PostgreSQL provisioning and signing-key issuance remain explicit owner operations. A source build or health response alone is not deployment proof.

Explicit self-host API URL/credential pairs are supported. The low-level createFeedbackClient({baseUrl, token}) can deliberately call an anonymous self-host service when token is omitted; it never consumes ambient credentials. feedback serve or feedback-serve --local selects the legacy local development server explicitly. Direct SQLite/JSONL storage adapters and the optional browser context helper remain compatibility exports; normal hosted clients do not use them. This package adds no application UI.