fix(sweep): replace the reply-reaction shortcut with the four-condition trigger gate

[carlos-alm]

The bug

Step 2g decided "is Greptile satisfied?" by checking for a positive reaction on the most recent non-Greptile comment — that is, on one of your own replies. A 👍 on a reply is not a re-review of your code. Under that rule the re-trigger is skipped while the fix sits un-reviewed — which is how a sweep reports a PR as converged when Greptile has never seen the change.

The fix

Transplant the four-condition gate the fleet standardised on. Satisfied now requires all of:

1. an @greptileai trigger comment exists — and really mentions Greptile. A literal inside a code span, fenced block, indented block or HTML comment notifies nobody and is not a trigger.
2. Greptile reacted positively to that trigger (never to a reply).
3. Greptile posted no issue-style or inline comment since.
4. Greptile has reviewed the current head, established from its own Last reviewed commit marker — not a commit timestamp. Greptile re-reviews by editing its summary in place, so timestamps cannot observe a completed re-review; a timestamp proxy re-triggers commits Greptile has already approved. Timestamps survive only as the fallback when no marker parses.

Every fetch failure fails safe by posting rather than assuming satisfaction.

Fitting it to this repo

• Step 2i (final mandatory re-trigger) added; Return result renumbered to 2j. The gate is designed to run twice, and its own header names Step 2i. That header doubles as the sentinel the shared test suite locates the gate by, so aligning this repo's numbering keeps one identical suite proving every fleet copy. I first tried the reverse — rewording the sentinel to say "Step 2h.1" to match the existing layout — and it immediately broke the suite's locator, which is the right outcome: that line is a fleet contract, not prose.
• The 50-trigger hard cap is preserved, and Step 2g's prose now says explicitly that the gate is not exempt from it — if the cap is spent, follow the cap's instructions instead of running the gate.
• The Step 2g prose was corrected. It still told the reader to "skip the actual trigger only if Greptile already reacted to your most recent reply" — the precise rule the gate exists to remove, and a direct contradiction of the code beneath it.

Verification

test_sweep_greptile_gate.py ported alongside. It extracts the real fenced block from SKILL.md — no copy — and runs it against fixture PR state behind a stub gh, under both bash and zsh (zsh because it is the maintainers' interactive shell, and a /sweep guard in a sibling repo once silently passed under zsh while failing its job, since zsh does not word-split an unquoted parameter).

Three of its six cases are mutation tests: they revert the gate to the pre-fix behaviour — remove the marker lookup, break the SHA regex, ignore a marker mismatch — and require the regression assertion to fail. Without them that assertion could pass with and against the bug it names.

6/6 on this branch. Wired into CI as sweep-gate.yml, path-filtered to the skill + suite — without it nothing ever executes this gate: it lives in Markdown, so it is shipped, load-bearing and otherwise entirely unproven.

Part of the fleet-wide sweep tracked by optave/data-retrieval-storage-svc#1021.

[greptile-apps]

Greptile Summary

The PR replaces the reply-reaction shortcut with a four-condition gate that verifies Greptile reviewed the current head and adds fail-safe handling for API and trigger-post failures.

• Adds a mandatory final gate execution before reporting sweep results.
• Tests the actual Markdown-embedded shell gate under bash and zsh using fixture-backed GitHub CLI behavior.
• Adds path-filtered CI coverage for the sweep skill and its regression suite.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
.claude/skills/sweep/SKILL.md	Replaces reply-reaction satisfaction with the four-condition current-head gate and routes all trigger paths through a checked posting helper.
.github/scripts/test_sweep_greptile_gate.py	Exercises the real embedded gate under bash and zsh, including marker handling, fetch failures, POST failures, and mutation regressions.
.github/workflows/sweep-gate.yml	Adds path-filtered CI execution for the sweep-gate regression suite.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Run re-trigger gate] --> B{Real trigger exists?}
  B -- No --> P[Post @greptileai]
  B -- Yes --> C{Positive reaction on trigger?}
  C -- No --> P
  C -- Yes --> D{No later Greptile comments?}
  D -- No --> P
  D -- Yes --> E{Current head reviewed?}
  E -- Marker matches --> S[Skip re-trigger]
  E -- Marker differs --> P
  E -- No marker --> F{Timestamp fallback satisfied?}
  F -- Yes --> S
  F -- No --> P
  P --> G{POST succeeds?}
  G -- Yes --> H[Exit successfully]
  G -- No --> I[Fail loudly]

Loading

_{Reviews (3): Last reviewed commit: "fix(sweep): the fail-safe recovery post ..." | Re-trigger Greptile}

[greptile-apps]

Trigger fetch aborts fail-safe gate

When the issue-comments request fails during Step 2g or mandatory Step 2i, this branch exits before attempting to post @greptileai, causing the sweep to stop without completing the required final review trigger.

[carlos-alm]

Fixed — the trigger-comments fetch now fails safe by posting @greptileai and exiting 0 instead of aborting the whole gate with exit 1. This matches every other guard in this block (head-SHA fetch failure, after-trigger-comment fetch failure, etc.), so a transient API error during Step 2g or the mandatory Step 2i can no longer silently stop the sweep short of the required final trigger. Added a new scenario (trigger_candidates_fetch_fails) plus a mutation test proving the fix is load-bearing to test_sweep_greptile_gate.py.

[greptile-apps]

Marker fetch failure permits false skip

When this issue-comments request fails after the initial fetch succeeded, the pipeline silently produces an empty reviewed_shas and enters the timestamp fallback. If the commit timestamp is no later than the trigger, the gate treats the head as reviewed and skips the mandatory trigger even though Greptile's current-head marker was never retrieved.

[carlos-alm]

Fixed — split the reviewed-commit marker fetch into its own gh api call whose exit status is checked directly with ||, before piping into grep. Previously the fetch was piped straight into grep -o, so a failed API call was indistinguishable from a successful call that legitimately found no marker yet (both left reviewed_shas empty and landed in the timestamp-proxy fallback) — meaning a fetch failure could get silently treated as 'satisfied' whenever the commit timestamp happened to predate the trigger. Now a fetch failure posts @greptileai immediately instead of falling through to the proxy. Added a new scenario (reviewed_shas_fetch_fails_must_not_fall_through) plus a mutation test proving the fix is load-bearing to test_sweep_greptile_gate.py.

[carlos-alm]

Addressed Greptile's review feedback (Confidence Score 3/5):

• Trigger-comments fetch (Step 2g gate): now fails safe by posting @greptileai and exiting 0 instead of aborting the whole gate with exit 1 on a failed fetch — matches every other guard's fail-safe pattern in this block, so a transient API error can no longer silently stop the sweep short of the required Step 2i final trigger.
• Reviewed-commit marker fetch (condition 4): split into its own gh api call whose exit status is checked directly, before piping into grep — a failed fetch used to be indistinguishable from a legitimate "no marker yet" and could fall through to the timestamp-proxy fallback, which could wrongly read "satisfied" and skip the trigger.
• Added two new scenarios (trigger_candidates_fetch_fails, reviewed_shas_fetch_fails_must_not_fall_through) plus two mutation tests to test_sweep_greptile_gate.py proving both fixes are load-bearing (now 8 checks total, all passing under both bash and zsh). Updated the module docstring and the sweep-gate.yml header comment that referenced "three mutation tests" to reflect the new total.

[carlos-alm]

@greptileai

[greptile-apps]

Recovery POST failure is ignored

When the trigger-comment fetch fails and the subsequent @greptileai POST also fails, this branch unconditionally exits successfully, causing the sweep to proceed without sending the mandatory final review trigger. The marker-fetch recovery branch has the same behavior.

[carlos-alm]

Fixed — and generalized beyond the two branches named here. Introduced a shared post_trigger_or_die helper that every posting branch in the gate now routes through (all 9: the two you flagged, the five other pre-existing fail-safe branches with the identical gap — trigger_ts empty, after-trigger-comment fetch failure, non-numeric page count, head_sha fetch failure, head_ts fetch failure — plus the 'no trigger exists' branch and the ordinary 'not satisfied' verdict, which had the same unchecked-POST issue). The helper exits 0 only if the @greptileai POST actually succeeds; otherwise it prints a loud FATAL message to stderr and exits 1, so a double failure (original fetch + recovery post both failing) can no longer silently report success. Added a scenario (trigger_fetch+trigger_post both failing) plus a mutation test proving this is load-bearing to test_sweep_greptile_gate.py (now 10 checks total, all passing under bash and zsh).

[carlos-alm]

Addressed the round-2 finding (Confidence Score 4/5 — "Recovery POST failure is ignored"):

• Introduced a shared post_trigger_or_die helper and routed all nine posting branches in the gate through it (the two you flagged, five other pre-existing fail-safe branches with the identical gap, the "no trigger exists" branch, and the ordinary "not satisfied" verdict). It exits 0 only if the @greptileai POST itself succeeds, otherwise it prints a loud FATAL message and exits 1 — a double failure (original fetch + recovery post both failing) can no longer silently report success.
• Added a scenario and a mutation test proving this is load-bearing to test_sweep_greptile_gate.py (now 10 checks total, all passing under bash and zsh).

[carlos-alm]

@greptileai