Feedback + OtiumWork roadmap

Every employee can suggest a feature, report a bug, or ask a question. There are three places to start:

• Topbar "Feedback ▾" dropdown (every page) → ✦ Suggest a feature / 🐞 Report a bug
• Sidebar footer — same two links
• /feedback directly — kind defaults to "feature" but is set by ?kind= query param, so the dropdown links route to the right form

What happens next depends on the kind.

Three separate boards — don't confuse them

1. /roadmap — OtiumWork's product roadmap. Visible to all users at all tenants. Vote on what OtiumWork should build next. This is where your /feedback feature requests land.
2. /admin/competitors/features — your company's internal tracker of your company's competitors (e.g., SoftInWay tracking Aspen's and NREC's feature sets for their AxSTREAM engineering product). Has nothing to do with OtiumWork as a tool. Scoped to your tenant.
3. /admin/feedback — raw feedback list, admin-only. For triaging bugs and questions.

Kind = feature

When you pick "feature request" and submit:

1. Entry saved to feedback_request table.
2. Auto-acknowledgment email confirms receipt, linking you to /roadmap.
3. Notification email to OtiumWork's product team.
4. Auto-promoted to OtiumWork's roadmap — a matching row with competitor=[User Request], tag CONSIDER, priority 3.
5. You (and every authenticated user at any tenant) can vote on it from /roadmap.

Voting to prioritize

On /roadmap (and also on your tenant's /admin/competitors/features for your own company's competitor features):

• ▲ N button next to every feature — click to cast your vote, click again to remove it. One vote per user per feature.
• Vote counts show live and sort order lifts high-vote items to the top within each tag — so a CONSIDER with 12 votes surfaces above a CONSIDER with 0 votes.

The OtiumWork product team uses /roadmap vote counts to sequence what gets built next.

Kind = bug / question

Bugs and questions go through the same pipeline (notification + auto-reply) but aren't auto-promoted to the roadmap — they're for the OtiumWork team to act on, not for voting.

Bug-triage workflow (Claude Code agent)

Bugs flow into a dedicated workflow that uses Valentine's Claude Code session as the fix-it loop — not an autonomous cron, not an API agent.

1. User submits at /feedback?kind=bug → row in feedback_request (kind='bug', status='open', triage_status=NULL).
2. Email pings the product owner.
3. Valentine opens Claude Code and asks "any new bugs?" or runs /triage — the agent (this is documented in CLAUDE.md at the repo root) calls scripts/triage_bugs.py list over SSH to surface open bugs.
4. Working through them in conversation: agent reads each bug, identifies the file, proposes a fix, Valentine says "go" or "skip".
5. On "go": agent applies, commits, deploys, and runs triage_bugs.py fix <id> <commit_sha> '<short note>' — that marks the row resolved AND emails the reporter automatically (idempotent via reporter_emailed_at).
6. For non-bugs: reject <id> 'reason' (not reproducible) or wontfix <id> 'reason' (by design). Both email the reporter.

Schema additions on feedback_request to support this: triage_status, triage_notes, fixed_commit_sha, resolved_at, reporter_emailed_at.

Admin view

/admin/feedback lists every submission with status. Bugs that have been triaged show their fixed_commit_sha and resolution status.

Closing the loop manually

Admins can also manually close a feedback item at /admin/feedback. Submitter gets an email saying it was marked resolved, with an optional note (e.g., "Shipped in v1.6.5" or "See /help/reports — this already works"). Submitter can reply to the email or re-submit if they disagree.