Problem
@gittensory chat (#4595) is currently maintainer/collaborator-only (DEFAULT_COMMAND_AUTHORIZATION_POLICY.commands.chat in src/settings/command-authorization.ts). A PR's own author -- the person who'd most naturally want to ask about their own PR -- is denied entirely, with no user-visible reply (silent audit-only skip).
The original v1 comment already signals this was meant to be temporary: "chat is Ollama-only grounded LLM generation, a materially larger surface than ask's deterministic-only answer, so v1 starts maintainer/collaborator-only."
Proposal
Add pr_author to chat's allowed roles, scoped to a PR's own author asking about their own PR (not any commenter on any PR).
Gate this on commandRateLimitPolicy being "hold" for the repo -- enforced in evaluateCommandAuthorization, not just by operational convention. The per-actor rate limiter (maybeThrottleGittensoryCommand) already exists, is keyed by (actor, command, repo#PR) (not a shared bucket), and already applies the tighter AI-cost ceiling to chat. Coupling the two in code (rather than trusting every deployment to configure both together) avoids repeating the exact class of bug from the gate.enabled: false / AI-spend independence issue, where two related settings silently drifted apart.
Net effect: repos that already have commandRateLimitPolicy: hold configured get this immediately; every other deployment (including third-party self-hosters who haven't turned on rate limiting) stays exactly as conservative as today.
Acceptance criteria
chat's default role list includes pr_author.- A
pr_author-only match for chat is only treated as authorized when commandRateLimitPolicy === "hold"; otherwise it falls through to the existing silent-skip path with a distinct, legible audit reason.
normalizeCommandRoleList's clamp still lets a maintainer explicitly restate/narrow chat's roles via .gittensory.yml without pr_author being silently stripped.- Every other maintainer-only command (
generate-tests, pause, resume, etc.) is completely unaffected -- pr_author still cannot be added to them via config.
- Full branch-coverage tests, including the compound on/off interaction.
Problem
@gittensory chat(#4595) is currently maintainer/collaborator-only (DEFAULT_COMMAND_AUTHORIZATION_POLICY.commands.chatinsrc/settings/command-authorization.ts). A PR's own author -- the person who'd most naturally want to ask about their own PR -- is denied entirely, with no user-visible reply (silent audit-only skip).The original v1 comment already signals this was meant to be temporary: "chat is Ollama-only grounded LLM generation, a materially larger surface than ask's deterministic-only answer, so v1 starts maintainer/collaborator-only."
Proposal
Add
pr_authortochat's allowed roles, scoped to a PR's own author asking about their own PR (not any commenter on any PR).Gate this on
commandRateLimitPolicybeing"hold"for the repo -- enforced inevaluateCommandAuthorization, not just by operational convention. The per-actor rate limiter (maybeThrottleGittensoryCommand) already exists, is keyed by(actor, command, repo#PR)(not a shared bucket), and already applies the tighter AI-cost ceiling tochat. Coupling the two in code (rather than trusting every deployment to configure both together) avoids repeating the exact class of bug from thegate.enabled: false/ AI-spend independence issue, where two related settings silently drifted apart.Net effect: repos that already have
commandRateLimitPolicy: holdconfigured get this immediately; every other deployment (including third-party self-hosters who haven't turned on rate limiting) stays exactly as conservative as today.Acceptance criteria
chat's default role list includespr_author.pr_author-only match forchatis only treated as authorized whencommandRateLimitPolicy === "hold"; otherwise it falls through to the existing silent-skip path with a distinct, legible audit reason.normalizeCommandRoleList's clamp still lets a maintainer explicitly restate/narrowchat's roles via.gittensory.ymlwithoutpr_authorbeing silently stripped.generate-tests,pause,resume, etc.) is completely unaffected --pr_authorstill cannot be added to them via config.