Problem
@gittensory mention commands exist, but several commands still produce generic top-action output. Maintainers and PR authors need command-specific, public-safe responses.
Desired behavior
Tailor public-safe output for these commands:
@gittensory preflight
@gittensory blockers
@gittensory duplicate-check
@gittensory miner-context
@gittensory next-action
Implementation notes
- Start in
src/github/commands.ts and related webhook handlers.
- Keep existing authorization: maintainers can invoke installed-repo commands; PR authors can invoke only on their own PRs when official miner detection passes.
- Non-miners, bots, unauthorized users, and miner detection outages should fail closed.
- Each command should have its own response builder instead of reusing one generic top-action block.
Public/private boundaries
Public comments must never include score estimates, payout/reward language, wallet/hotkey data, raw trust scores, or private reviewability internals. Keep comments advisory and maintainer-friendly.
Acceptance criteria
- Each supported command produces distinct output.
- Unauthorized users receive no visible public response unless an existing policy explicitly allows a sanitized denial.
- Miner context confirms only public-safe official miner status.
- Duplicate-check reports public-safe collision/WIP context without internal labels like
likely_duplicate.
- Existing sticky-comment/update behavior remains non-spammy.
Tests
- Command parser coverage for every command.
- Maintainer authorization.
- PR author authorization.
- Non-miner, bot, and API-outage fail-closed cases.
- Public sanitizer regression.
Problem
@gittensorymention commands exist, but several commands still produce generic top-action output. Maintainers and PR authors need command-specific, public-safe responses.Desired behavior
Tailor public-safe output for these commands:
@gittensory preflight@gittensory blockers@gittensory duplicate-check@gittensory miner-context@gittensory next-actionImplementation notes
src/github/commands.tsand related webhook handlers.Public/private boundaries
Public comments must never include score estimates, payout/reward language, wallet/hotkey data, raw trust scores, or private reviewability internals. Keep comments advisory and maintainer-friendly.
Acceptance criteria
likely_duplicate.Tests