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.

Much of step 3–5 also runs autonomously through staging via the fix-it runner (see below); production always stays a human gate.

Staged-for-review + approvals (staging → prod)

Fixes are reviewed on the staging site before they reach production. The bug view (/admin/feedback) shows where each item is:

Status	Meaning
◧ On staging	Fixed on the internal staging site otiumdevelopment.softinway.com (VPN-only; branch + commit shown). Awaiting developer review.
✓ Dev-approved	A developer verified it on staging and signed off. Waiting for the weekly prod go.
▶ Prod-approved	The owner approved release; the promoter will ship it.
✓ Live	Shipped to production; reporter emailed.

Who does what:

• Developers (accounts with the developer flag) see the staging branch/commit + a "Review on staging ↗" link, and a ✓ Dev-approve button to confirm the fix is correct.
• The owner gets a weekly Telegram digest of dev-approved items and clicks ▶ Approve for prod. Running deploy/promote-approved.sh then promotes just those fixes (isolated cherry-pick) and closes them.

Emails: the whole dev team (owner + developers) is auto-emailed on every new report and every status change. The person who filed the item is emailed twice: once when it's fixed on staging (pending release) and again when it goes live.

Schema on feedback_request: triage_status (triaged → staged → dev_approved → prod_approved → fixed), triage_notes, fixed_branch, fixed_commit_sha, staged_at, staged_emailed_at, dev_approved_by/at, prod_approved_by/at, resolved_at, reporter_emailed_at.

Admin view

/admin/feedback lists every submission with status. Developers additionally see the staging branch/commit, a review link, and the approve buttons described above.

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.