Inspector, Feedback

In the Inspector app, Feedback is a top-level sidebar destination at /feedback, alongside Dashboard and Conversations, not under /settings. It is the in-product channel for reporting friction with Neotoma: failing tool calls, opaque errors, missing surfaces, doc gaps. The UI exposes the same submit_feedback + get_feedback_status primitives that agents use over MCP, with redaction previews and a status feed.

Submission modes

• proactive Default. Agents submit feedback on friction without asking each time; the Inspector will still ask before submitting on behalf of the operator from this UI.
• consent Ask for consent on every submission, including agent-initiated ones.
• off Do not submit feedback automatically. Agents must be told explicitly to submit.

Admin unlock

The feedback admin queue starts by calling /admin/feedback/preflight with credentials: "include". If preflight reports no active admin session, the Inspector requests a one-time challenge and shows neotoma inspector admin unlock --challenge ... (or run unlock without a challenge). The CLI redeems with its AAuth signer and prints a URL to the Inspector /feedback/admin-unlock page, which calls /admin/feedback/auth/session to set the short-lived httpOnly cookie.

Admin routes accept only direct hardware, software, or operator_attested AAuth requests, or the local session minted from one of those tiers. Bearer tokens, OAuth cookies, and generic clientInfo do not unlock the queue.

PII redaction

Feedback submissions go through a redaction pass before they leave the instance. Emails, phone numbers, API tokens, UUIDs, and home-directory path fragments are replaced with <LABEL:hash> placeholders. The endpoint applies a backstop redaction pass on top and returns a redaction_preview, which the Inspector renders as a diff before final submit so you can audit what actually leaves your machine.

Required environment metadata

Every submission carries:

• neotoma_version, client_name, os, the minimum environment fingerprint.
• tool_name, invocation_shape, what was being tried.
• error_message, error_class, hit_count, the failure mode and recurrence.

Status feed & verification

Submitted items return an access_token + a suggested next-check time. The Inspector polls get_feedback_status in the background and updates the recent-submissions table when status changes. When a submission is marked shipping (verify), the panel surfaces an upgrade_guidance block with the install commands and a verification step; submitting that step closes the loop with a fix_verification follow-up.

Where the access token lives

Tokens are stored in Neotoma as product_feedback entities and never echoed back into chat or logs. Browse them under Entities → product_feedback if you need to reconcile what was submitted from this instance.