Problem
When Forge repeatedly misdiagnoses a CI failure because it lacks project-specific context, reviewers cannot guide the next automated fix from the pull request. Their current choices are to fix the code manually, skip the gate, wait for retries to exhaust, or manipulate workflow state.
Forge should accept bounded human guidance while retaining an auditable, policy-controlled CI repair loop.
Proposed behavior
Add a GitHub pull-request command:
/forge hint <context for the next CI fix>
Examples include identifying a required service, explaining a repository convention, or pointing Forge toward the relevant failing component.
When an authorized collaborator submits a hint, Forge should:
- Record an append-only hint entry containing the text, actor, timestamp, repository/PR identity, and consumption status.
- Grant exactly one additional CI fix attempt. A hint must not reset the complete retry budget.
- If the current CI result is failed or the normal fix budget is exhausted, refetch current check state/logs and schedule the additional attempt immediately.
- If checks are still running, retain the hint and consume it on the next failed result.
- Inject all unconsumed hints into that attempt's fix context, then mark them consumed.
- Post an acknowledgement on the PR and an audit entry on Jira.
Multiple hints are retained rather than replacing one another. Replayed webhook deliveries must not grant duplicate attempts or duplicate hint entries.
Safety and policy
- Accept the command only from users authorized to influence the repository/PR.
- Apply a configurable length limit and treat hint text as untrusted external input.
- Never interpret hints as executable commands or scheduling policy.
- Preserve hint provenance in workflow history and tracing.
- A hint may add one attempt only; repeated hints remain visible and attributable.
- Ignore bot-authored acknowledgement comments to prevent loops.
Out of scope
- Scheduled or recurring infrastructure retries such as “retry hourly” or “retry at 04:00.”
- Changing whether infrastructure failures count against the ordinary CI budget.
- General-purpose workflow instructions outside CI repair.
Those behaviors require a separate CI retry-policy design with time, quota, and infrastructure-failure semantics.
Acceptance criteria
/forge hint ... is recognized on an implementation PR during CI-related and CI-exhausted states.
- Each unique authorized hint grants exactly one additional attempt, without resetting the normal budget.
- A currently failed/exhausted workflow acts on the hint without requiring another external CI event.
- A hint received while checks are running is retained for the next failure.
- Multiple unconsumed hints are included with actor attribution and then marked consumed.
- Duplicate deliveries do not duplicate hints, attempts, GitHub replies, or Jira audit comments.
- Empty, oversized, unauthorized, and bot-authored commands are rejected or ignored with appropriate feedback.
- Tests cover active failure, exhausted budget, running checks, multiple hints, authorization, replay, and audit behavior.
Context
Converted from proposal PR #17 after refinement. The original proposal used a single replaceable hint and reset the entire retry budget; this issue adopts an append-only model and one bounded additional attempt per hint.
Problem
When Forge repeatedly misdiagnoses a CI failure because it lacks project-specific context, reviewers cannot guide the next automated fix from the pull request. Their current choices are to fix the code manually, skip the gate, wait for retries to exhaust, or manipulate workflow state.
Forge should accept bounded human guidance while retaining an auditable, policy-controlled CI repair loop.
Proposed behavior
Add a GitHub pull-request command:
Examples include identifying a required service, explaining a repository convention, or pointing Forge toward the relevant failing component.
When an authorized collaborator submits a hint, Forge should:
Multiple hints are retained rather than replacing one another. Replayed webhook deliveries must not grant duplicate attempts or duplicate hint entries.
Safety and policy
Out of scope
Those behaviors require a separate CI retry-policy design with time, quota, and infrastructure-failure semantics.
Acceptance criteria
/forge hint ...is recognized on an implementation PR during CI-related and CI-exhausted states.Context
Converted from proposal PR #17 after refinement. The original proposal used a single replaceable hint and reset the entire retry budget; this issue adopts an append-only model and one bounded additional attempt per hint.