[maxigimenez]

Two independent reasons the reviewer route could not run, both found on the live runner. Either alone is enough to keep it silent forever.

1. A review that is already outstanding is unreachable

This is the one that matters, and it is not a configuration mistake.

• reviewersAdded fires only on the single cycle that observes the request appear. A review asked for before the route existed, or while the runner was down, is lost permanently.
• Re-requesting does not recover it. A reviewer who has not yet reviewed never leaves requested_reviewers, so removing and re-adding them inside one ~25s poll window is invisible. Winning that race is not a reasonable thing to ask of an operator.

The catalog recorded this as an accepted limitation. It shouldn't have been one.

Matching on the state — "a review is outstanding" — is true for as long as it is true, which is exactly what's needed. What made state clauses unusable was the dedupe key: a PR's revision moves on every push, so under per-change each commit started another review round.

while-matched separates still waiting from asked again: claim the item on the first cycle it matches, hold the claim while it keeps matching, release it when it stops.

• dedupeKey drops the revision, as once does — pushes and replies cannot re-fire it.
• releaseUnmatchedClaims re-arms the route when the condition lapses. For a review that's the agent answering it: GitHub clears the request and the trigger stops being raised at all.
• A claim whose run has not settled is never released. Mid-run the item carries sentinel0:in-progress and so stops matching by construction; releasing on that basis would re-arm the route against work it is still doing.
• collectEvents returns undefined on failure, not []. A tracker outage read as "nothing matches any more" would release every claim and replay the lot. The project is skipped instead and the cycle summary says unavailable.
• The shipped reviewer template moves to while-matched + match.reviewers.

Enabling such a route acts on everything already matching. That is the point — it is how a waiting PR finally gets picked up — and it is documented rather than hidden.

2. explain hid a broken target behind an unrelated clause

Matching and targeting fail independently, and explain reported only the first failing match clause:

skips    Reviewer agent: match.reviewersAdded wants any of [EomiAIBot]; ...

True, but that route also addressed a GitHub identity no Hermes profile claims — all four profiles on the runner had no githubLogin, so resolveAgent could never find one and the route would have died as unknown-agent the day it matched. Until then it read as an ordinary "did not match", and two rounds of debugging went into the clause that merely came first.

• resolveAgent and explainTarget move into the rule engine and are shared with the dispatcher, so the diagnostic gives the answer dispatch would give.
• explainTarget separates no agent has that identity from the agent is disabled, and names the profiles carrying no githubLogin plus the file to set it in.
• The target is evaluated for every route on every item regardless of the match, printed in red as broken.

      skips    Reviewer agent: match.reviewersAdded wants any of [EomiAIBot]; ...
      broken   Reviewer agent: no enabled agent has githubLogin "EomiAIBot"
               (eomi, james, kitt have no githubLogin set — see
               hermes.profiles[].githubLogin in ~/.sentinel0/config.json)

Covered

while-matched: fires with no transition to observe · holds one claim across pushes · re-arms after the request is answered and fires again when asked again · keeps the claim while the item still matches · never releases a running or approval-blocked run · re-arms after a failure so a retry is possible · touches no other route's claims.

Targeting: resolution by profile and by login, disabled vs missing, a target naming neither, and the exact production shape — match fails on reviewersAdded and the unresolvable target is reported alongside it.

593 tests pass across all five packages; lint and build clean.

Upgrading

Both fixes are needed, and so is one piece of configuration this cannot do for you: set hermes.profiles[].githubLogin in ~/.sentinel0/config.json so a profile declares which GitHub account it acts as. Nothing verifies it, preflight only warns, and without it the route resolves no agent.

Then switch the existing route to while-matched + match.reviewers and every PR already waiting on the agent is picked up on the next cycle — including ones that were previously unreachable.

Releases 0.0.7.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QNEqbFkMFoPiiVnJGxpjj2