The entire operating loop can be directed from Telegram without giving the machine permission to ship on its own.
Everything. Product, design, brand, and engineering. A solo build.
01 / Problem
A user knows what felt broken. They usually do not know which route, request, build, device, or system event will explain it. By the time a report reaches the person who can act, the original context has been separated from the complaint.
The second problem is operational. A solo owner or small team does not need another dashboard to monitor. They need a fast way to decide what matters, keep a backlog, communicate with the person who reported it, and send the right work to the right coding agent.
The QA agent joins those two needs. It captures evidence inside the product, then turns Telegram into a mobile control plane for the complete ticket lifecycle.
System
Next.js product proxy
The goal was not another bug form. The goal was a QA operation I could run from anywhere.
02 / Intake
A persistent Feedback & Bug Reports control is available throughout Dumpster Fire. It opens over the current screen, so a user can describe what happened without leaving the task that exposed the problem.
Benefit
Less reconstruction. Faster diagnosis. A lower reporting burden for the user.
Raw credentials, authorization values, uploaded files, and unrestricted browser logs are not included.
03 / Record
The site sends the report through a time-boxed Next.js proxy to a separately deployed QA relay. The relay validates the payload, derives a normalized ticket, writes the ticket and its first event to Postgres, and posts an owner card to Telegram.
Triage is deterministic. The relay classifies the report by type, estimates severity from P0 through P4, identifies the likely product area, summarizes the expected behavior, and suggests a next action. It recognizes bugs, data and integration failures, performance and accessibility issues, security and privacy concerns, account problems, responsive layout problems, feature ideas, duplicates, and known issues, among others.
No model required
No coding agent is needed to create, classify, or store the ticket. Model execution begins only after an authorized owner chooses it.
04 / Control
Every new ticket arrives as an actionable Telegram card. From a phone, the owner can understand the report, decide whether it belongs in the backlog, communicate with the reporter, route development work, or close the issue.
Common decisions are buttons. Deeper inspection is available through short commands. The database remains the source of truth while Telegram provides the fastest path to action.
Benefit
No desk and no separate admin application required to keep QA moving.
Understand the report
Control the queue
Monitor the operation
05 / Backlog
Backlog ticket
One report, five owner choices
Moving a report to backlog changes the available actions. The owner can reopen the ticket from Telegram and choose its development route at any time.
Batching is deliberately a discussion step. Marked tickets can be reviewed together in a coding-agent conversation, which returns a numbered decision list. Nothing is queued for implementation until the owner chooses the next action for each ticket.
Benefit
Small issues wait. Related issues group. Important issues move now. The queue reflects human priorities rather than agent eagerness.
06 / Agents
Each installation can expose Codex, Claude, or both. Telegram only offers a provider when that worker is configured and connected. Selecting an agent creates a provider-specific task packet with the ticket, repository, project context, local rules, QA guidance, and expected evidence.
Before work begins, the worker fast-forwards to the current origin/main. The coding agent can inspect, edit, test, and summarize inside its isolated checkout, but it has no network access and no authority to commit, push, or deploy.
Run with Codex
Run with Claude
What stays consistent
Same ticket. Same project rules. Same repository boundary. Same evidence requirements. Same approval gate.
Codex and Claude never share a working directory. The workflow is provider-flexible without becoming process-fragmented.
07 / Progress
Telegram receives durable receipts as a task is queued, claimed, started, blocked, failed, completed, rerun, discarded, or canceled. A running task is never force-canceled because it may already have changed the workspace.
The review card returns
If a worker stops after changing files, the patch is salvaged as a high-risk review item rather than silently discarded.
08 / Authority
Applies the reviewed change through the controlled review worker.
Archives the original patch, cleans the workspace, synchronizes, and queues a new attempt.
Archives the exact patch before removing the verified task-owned changes.
If main changed after the task ran, approval disappears. The stale patch can be archived and rerun, but it cannot be pushed as if it were current. If the workspace contains unrelated changes or cannot be verified cleanly, the action stops and returns an explanation.
Mobile control does not mean casual deployment. Every consequential action remains explicit.
09 / Replies
If the reporter provides an email address, the owner can compose an acknowledgement from Telegram. The draft begins with the project's own canned response and tone, then remains pending until it is reviewed. The owner can preview it, edit it through Telegram's native reply prompt, send it, or discard it without changing the ticket.
A successful initial acknowledgement leaves the ticket open. A successfully delivered fixed follow-up closes it. Failed or timed-out delivery does not pretend the message was sent: the reply stays pending, failure metadata is recorded, and a fresh approval is offered for retry.
Benefit
The same mobile workflow that manages code also keeps the reporter informed, with delivery truth preserved in the record.
Dumpster Fire receives the signed callback and sends through its own email provider, credentials, and brand voice.
10 / Portability
QA-AGENT is a factory for independent project agents. A new product receives a complete copy of the operating core, then owns its own context and infrastructure. There is no shared project switcher and no central bot carrying context between clients.
Running install:new creates an independent application. Running it again refreshes the portable core while preserving install identity, environment values, local data, outbox evidence, rules, tone, QA notes, canned responses, custom actions, and plugins.
Dumpster Fire
Project-owned
Repository, bot, admins, database, deployment, context, rules, tone, canned replies, agents, email delivery, custom actions
Portable core
Validation, triage, records, Telegram controls, worker lifecycle, review controls, health and smoke checks
Nothing shared
Your next product
Project-owned
Its own repository, bot, admins, database, deployment, voice, rules, and secrets
Portable core
Installed with install:new as the same operating model
The workflow can move to another product without moving Dumpster Fire's users, secrets, data, voice, or repository access with it.
11 / Guardrails
The runtime cannot switch into a sibling project because none exists inside it.
Webhook secret, bot, project, ticket, approval, action, expiry, and administrator chat are validated before anything runs.
Stale, copied, malformed, expired, or already-used callbacks fail closed.
Telegram presents the controls. Postgres stores tickets, tasks, approvals, deliveries, and audit history.
Separate clean clones per provider. A provider mismatch or reused workspace fails closed.
The coding agent has no network access and cannot commit, push, or deploy during execution.
The repository is synchronized before execution and checked again before approval. Stale results cannot expose a push.
A local reply file is labeled local. A queued task is labeled not started. A failed webhook is labeled failed.
An unavailable QA service does not make the customer-facing product unavailable.
12 / Extension
An installation can register custom actions for its own product. They can be packaged, checksummed, verified, imported, and activated without introducing a shared multi-project backend. The portable core stays reusable while product-specific behavior stays owned by the product.
Dumpster Fire actions
Mark a stale job
13 / Outcome
QA became an operating loop instead of an inbox.
Dumpster Fire now has a direct path from user friction to accountable action. Reports preserve context. Tickets become a visible backlog. The owner can communicate with the reporter, choose a coding agent, follow the work, review evidence, and decide what reaches the repository from a mobile phone.
The larger result is a reusable operating model. Each product can have the same capabilities without sharing its data, credentials, bot, repository, tone, or release authority.
Portable enough to install anywhere. Constrained enough to trust. Simple enough to run from a phone.
AI Systems Product Operations Quality Assurance Workflow Design