# Broccolini Bot – Roadmap & Proposal

Short proposal and possible next steps for the Broccolini Bot ticketing system. Discord + Gmail + MongoDB remain the core; any extension is additive.

---

## Current State

- **Email → Discord:** Gmail poll creates ticket channels/threads; replies sync back to Gmail.
- **Discord-first:** Panels, slash commands, buttons, modals, context menus for full ticket lifecycle (claim, close, escalate, tag, priority, transfer, move, saved responses).
- **MongoDB:** Single data store for tickets, transcripts, tags, close requests, guild settings, and (optional) account info.
- **Automation:** Auto-close, reminders, auto-unclaim, claim timeout; all configurable via `.env`.
- **Security:** HTML escaping in outbound emails; test env workflow; optional healthcheck host binding.

No external ticketing API (e.g. Zammad) is used; the bot is self-contained.

---

## Possible Next Steps

### 1. Read-only API layer

- Expose ticket and metadata via a **read-only** HTTP API (e.g. alongside the bot or a small separate service).
- Endpoints: list/filter tickets, ticket by ID, “my tickets” by Discord ID, tags, guild settings.
- Enables dashboards, mobile tools, or a **Support Cockpit** (bOSScord-style overlay) without changing Discord or bot behavior.
- Optional: use something like Directus on top of MongoDB for instant REST/GraphQL and admin UI.

### 2. Ticket routing & queues

- Derive a **queue** (or routing bucket) per ticket from game detection (`GAME_LIST`), subject/body keywords, and existing tags.
- Store queue on the ticket document; show it in Discord (e.g. in embeds or channel name) and in any future API/UI.
- Enables “Network”, “Billing”, “Mod Help”, “Game X” views without changing how staff use Discord.

### 3. Incident & problem tracking

- **Incident:** one-off “something broke” ticket.
- **Problem:** recurring issue; link multiple incidents, track root cause, workaround, and fix status.
- Optional new commands or buttons to “Link to problem” / “Create problem from ticket” and optional API fields.

### 4. Knowledge base & PM links

- Internal KB (e.g. Wiki.js): link from problems/tickets to articles; optional `/kb search` in Discord.
- PM tool (Plane, Focalboard, Taiga): “Create PM task from ticket” and link ticket ↔ task.
- Broccolini Bot stays the source of truth for tickets; KB and PM are linked data.

### 5. bOSScord / Support Cockpit

- Web (later desktop) client that **reads** from the API and MongoDB.
- Richer views: queues, SLA-style status, “who’s viewing this ticket”, virtual display names, links to KB and PM.
- All writes and communication remain in Discord; the client is view/routing only.

### 6. GitHub / GitLab (optional)

- From a problem or PM task: create issue/PR with context.
- Webhooks to update problem/task when issues close or PRs merge.

---

## Principles

- **Discord + Broccolini Bot are canonical.** New features augment, they don’t replace, the current flow.
- **API-first for new UIs.** Any dashboard or cockpit consumes a read-only (or narrowly write) API; no direct DB access from frontends.
- **Config and secrets stay in `.env`.** New services get their own env or reuse existing vars where it makes sense.
- **MongoDB remains the primary store.** New collections or fields as needed; no second database unless justified.

---

## No Deadlines

This document is a proposal and idea list. Work can proceed in small steps: e.g. add a read-only ticket API, then add queue derivation, then plug in a simple dashboard or bOSScord.

For a fuller platform vision (bOSScord, queues, incidents/problems, KB, PM), see the parent repo’s bOSScord proposal if present.