dev: Forge ignores PR review comments when developer shares the bot's GitHub account

[ekuris-redhat]

Problem

When developing locally with a personal GitHub account used as the Forge bot token, submitting a PR review comment as yourself is silently dropped by Forge. No error is surfaced — the workflow simply does not advance.

Root cause: Forge detects its own comments by comparing sender.login from the webhook payload against the login returned by GET /user (the authenticated GitHub token owner). In a dev setup where the developer's GitHub account is the bot account, these are always equal — so every comment the developer posts looks like a Forge self-comment and is skipped.

This affects three filter sites in the worker:

• Inline PR review comments (review_response_gate)
• Issue comments on PRD proposal PRs
• Issue comments on spec proposal PRs

Proposed solutions

Three options for team discussion — they are not mutually exclusive.

Option A — Comment prefix (FORGE_COMMENT_PREFIX)

Forge signs every GitHub comment it posts with a configurable hidden prefix (e.g. <!-- forge-bot -->). Self-comment detection checks for the prefix in the comment body rather than comparing logins.

• New config: FORGE_COMMENT_PREFIX (empty = disabled, falls back to login check)
• On post: all create_issue_comment and create_review_comment calls prepend the prefix
• On receive: comment body starts with prefix → skip; otherwise → process
• The <!-- ... --> HTML comment syntax renders invisible in GitHub markdown

This is the most targeted fix. A developer's hand-written comments never carry the prefix, so they're never dropped, regardless of which GitHub account Forge uses.

Option B — Explicit bot login override (FORGE_GITHUB_BOT_LOGIN)

New config FORGE_GITHUB_BOT_LOGIN hard-codes the GitHub username Forge compares against instead of calling GET /user at runtime.

• In production: set to the dedicated bot account login
• In dev: leave empty to disable the login check entirely (all comments are processed)
• Pro: no changes to comment content
• Con: disabling the check means Forge has no self-comment protection in dev — potential for Forge to react to its own comments if the config is accidentally left unset in production

Option C — Dedicated GitHub App

Switch from a PAT to a GitHub App for local development as well. Comments posted by a GitHub App carry a [bot] suffix in the sender login (e.g. forge-dev[bot]), giving Forge a distinct identity from the human developer. The existing login comparison already handles this case correctly.

• Pro: zero code changes; proper identity separation at the platform level
• Con: heavier one-time setup (register App, install on repos, configure private key + app ID); less practical for a fast local dev loop

Suggested default

Option A as the code-level fix, with Option C as the longer-term architecture for teams that want a clean prod/dev identity boundary.