Reporter Role & Client Feedback
A UAT-friendly permission level for external clients to report issues without seeing your workspace.
The reporter role is a scoped permission level that lets external people — UAT testers, beta users, agency clients — report issues against your project without ever seeing your memories, decisions, agents, or workspace internals. They get a dedicated reporter dashboard that only shows what's been explicitly shared with them.
Good fit for
- • Dev agencies running UAT with end clients
- • SaaS teams soliciting beta feedback
- • Product owners who need visibility without access to code memories
- • External stakeholders on milestone reviews
Not a fit for
- • Team members who need to create memories or decisions → use write role
- • People who need to see agent traces or workflows → use read role or higher
- • Admins managing team or billing → use admin or owner
- 1Go to the Team page. From the dashboard sidebar, open Team → Invite Member.
- 2Enter their email and select role “Reporter”. The form shows the reporter role with a small icon and a short description of what they'll see.
- 3Pick the namespaces they should see. The namespace selector defaults to
none— tick each namespace you want them to access. Leave them out of anything they shouldn't see. - 4Send the invite. They receive a magic-link email. On first click, they land on
/dashboard/reporter— not the main dashboard.
Security default: namespace pre-fill is “none”
v3.0.72 hardened the invite form so no role auto-inherits namespaces. Before, reporters were accidentally granted every org namespace on invite. Now, the admin must explicitly tick each namespace the reporter should access. This applies to all roles, not just reporters — it's the platform-wide default.
/dashboard/reporter experienceReporters never see the main dashboard. On login they're routed straight to the reporter dashboard, which is scoped to the namespaces they've been granted.
Reporters CAN see
- • Shared plans (read-only) for the namespaces they're in
- • Their own issues list with status timeline
- • Issue comments thread on their own issues
- • Their profile and account settings
Reporters CANNOT see
- • Memories, decisions, architecture
- • Agents, workflows, genome, observer
- • Other reporters' issues
- • Team settings or billing
- • Any namespace they weren't explicitly granted
Namespace isolation (v3.0.72 P0 fix)
Reporters ONLY see data in namespaces they were explicitly granted. They cannot enumerate other namespaces, traverse the namespace hierarchy upward, or see other reporters' submissions. This is enforced at every API route — not just in the UI — with regression tests that ship alongside every release.
- 1Open a shared plan. Reporters see plans the admin has marked as shared with their namespace.
- 2Click “Report Problem” on any task. Every task in a shared plan has a button that pre-populates the issue with the plan + task context (deep link back to the task, task title, current status).
- 3Describe the issue and attach screenshots. The issue form accepts free-text description plus image attachments (5 MB max per file, images only). See Issue Attachments in core concepts.
- 4AI-assisted triage runs automatically. The ErrorTrackerAgent structures the description, suggests severity and tags, and detects duplicates against existing issues in the namespace. Reporters don't see this step happen — they just submit and move on.
- 5The issue is routed to namespace admins. Admins receive an email notification with the title, severity, screenshot thumbnails, and a link back to the plan context. Parent-namespace admins are also notified if the issue is filed in a child namespace.
Reporter issues land in the normal /dashboard/issues list alongside internally-created issues. They're flagged with a reporter badge so you can filter to just client submissions.
Acknowledge
Move the issue from Reported to Acknowledged. The reporter gets an email notification that you've seen it. Use this as a fast first-touch response even before you have a fix.
Comment
The issue comment thread is the conversation between admins and the reporter. Reporters see and can reply to admin comments on their own issues. Other reporters don't see any of this.
Status transitions
The status timeline runs Reported → Acknowledged → In Progress → Resolved. The reporter sees this as a visual IssueStatusTimeline component on their dashboard. Every transition triggers a status-change email.
Close-out
Mark as Resolved with a close-out comment explaining the fix. The reporter is notified and the issue moves off their active list (still visible in history).
| Event | Who gets emailed |
|---|---|
| Reporter invited | The reporter (magic link) |
| New issue submitted by reporter | Namespace admins + parent namespace admins |
| Admin acknowledges / transitions status | The reporter who filed the issue |
| Admin comments on reporter's issue | The reporter |
| Reporter comments on their own issue | Namespace admins |
A reporter is still a team member, so they count against your plan's member limit. They don't consume API quota because they operate via the dashboard UI only.
Included reporter seats by plan
- • Free: 1 member total (you) — no reporter seats available
- • Starter: 5 members (mix of reporters + team)
- • Pro: 10 members + £3/extra
- • Founder: 25 members + £3/extra
- • Enterprise: unlimited
What reporters DON'T consume
- • API weekly quota (no REST/MCP access)
- • Memory count (no memory creation)
- • Namespace count (they use existing namespaces)
- • Agent/workflow runs (no agent access)
Related: Team Management • Issues & Attachments • Plans