Add /feedback and /botbug commands for the bot's own iteration

[Kingvic300]

Summary

Add /feedback and /botbug commands so the bot's own maintainer(s) get a lightweight, low-friction channel for issues/suggestions about the bot itself, surfaced as GitHub issues rather than lost in chat scrollback.

Background

This session alone added 35 open issues to txio-telegram-bot covering substantial new functionality (per-repo routing, review notifications, releases, commands, scheduling, etc.). As that surface grows, friction encountered by actual users of the bot (wrong formatting, a command that doesn't behave as expected) currently has no capture mechanism other than someone remembering to open a GitHub issue manually.

Proposed Solution

/feedback <text> and /botbug <text> post the submitted text as a new GitHub issue on txio-telegram-bot (tagged feedback or bug respectively), crediting the submitter, using the GitHub API client from issue #4 (requires issues:write scope, same requirement noted in issue #6).

Technical Scope

• src/telegram/client.ts — bot.command("feedback", ...), bot.command("botbug", ...)
• Reuses src/github/api.ts from issue Add release published notifications #4, extended for issue creation (write access)
• Tests: issue-creation payload formatting, empty-text handling

Acceptance Criteria

• /feedback <text> creates a GitHub issue labeled feedback with the submitted text and submitter attribution
• /botbug <text> creates a GitHub issue labeled bug the same way
• Empty/missing text argument produces a usage message, not a blank issue
• Confirmation message posted back to the submitter with a link to the created issue
• Unit tests added
• CI passes
• Code follows project conventions

Edge Cases

• Rate limiting / spam — a single user submitting many /feedback calls in a row could flood the issue tracker; consider a basic per-user rate limit
• Very long submitted text exceeding GitHub issue body practical limits — truncate with a note rather than fail silently

Risks

• Requires write access to create issues (broader token scope than the read-only lookups in issue Add release published notifications #4/Add label-based notification filtering per routing destination #7/Harden and document workflow run event coverage (cancelled runs) #8) — same scope consideration as issue Add issue and PR comment notifications #6
• Spam/abuse risk is the main design concern; worth a basic rate limit before shipping

Deliverables

• Feature implementation
• Unit tests

Labels

enhancement, backend

Priority

Low — nice-to-have iteration tool, not blocking anything else in this backlog.

---

Estimated Completion: 96 hours

Telegram: https://t.me/txioCommunity

---

[EmmaxNuel]

Can i work this please?

[EstherIkechukwu]

I have gone through the description expect a pr in less than 24hrs

[Eco468]

I can take on this task if you give me the chance

[grantfox-oss]

🦊 GrantFox — @EmmaxNuel has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #45)
2. Your PR will be reviewed by the Txio-labs maintainers

Good luck! Track your progress on GrantFox.

[Kingvic300]

📢 Need help or have questions on this issue? Join the Txio Telegram community for support: https://t.me/txioCommunity

[BigJohn-dev]

Assign me pls

[grantfox-oss]

🦊 GrantFox — @BigJohn-dev has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #45)
2. Your PR will be reviewed by the Txio-labs maintainers

Good luck! Track your progress on GrantFox.