First upload

docs/features/PROPOSAL.md

@@ -0,0 +1,72 @@
+# 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.