feat: add eval for filtering invalid values before lazy fallback

[martinfrancois]

Problem

The Java Optionals skill should recognize that an Optional used for fallback
selection must contain only values that are semantically usable by the present
branch. Successful parsing alone is not enough. When a parsed value violates
the domain contract, filter(...) should turn it into absence before a lazy
fallback is selected.

This is eval-worthy because Duration.ofSeconds(...) accepts negative values,
while Thread.sleep(Duration) treats a negative duration as a no-op. An
Optional<Duration> that contains -1s therefore bypasses the intended retry
backoff even though the Optional pipeline looks structurally correct.

Java baseline: Java 25.

Code before the prompt was executed

The retry path preferred a Retry-After header and lazily computed exponential
backoff when the header was absent or unparsable:

private static Duration backoff(EffectiveConfig config, int attempt, HttpResponse<?> response) {
    Optional<Duration> retryAfter = response == null
            ? Optional.empty()
            : response.headers().firstValue("Retry-After").flatMap(TrelloClient::parseRetryAfter);
    return retryAfter.orElseGet(() -> exponentialBackoffWithJitter(config, attempt));
}

private static Optional<Duration> parseRetryAfter(String value) {
    try {
        return Optional.of(Duration.ofSeconds(Long.parseLong(value)));
    } catch (NumberFormatException e) {
        return Optional.empty();
    }
}

This shape was introduced in a large initial service implementation. The exact
original implementation prompt is unavailable; the nearest recoverable
requirement is that retryable Trello responses honor Retry-After and
otherwise use exponential backoff.

Prompt that caused the implementation

The nearest recoverable product requirements were:

The adapter SHOULD use bounded exponential backoff with jitter for retryable
Trello transport errors and 429 responses.

The adapter SHOULD honor response retry hints such as Retry-After if Trello
provides them.

The Optionals skill should activate when implementing this header-to-fallback
selection because absence controls non-trivial fallback work.

Later prompt that exposed the issue

A reviewer later identified the semantic gap:

Thread.sleep(Duration) treats a negative duration as a no-op, so
Retry-After: -1 skips backoff. Reject or ignore a negative Retry-After and use
the existing exponential fallback. Preserve positive behavior and add a
regression test.

Prompt-produced or reviewed code

The reviewed code is the pre-prompt code above. Its lazy Optional fallback is
the right broad structure, but parseRetryAfter(...) treats every numeric
duration as present:

return Optional.of(Duration.ofSeconds(Long.parseLong(value)));

Because Duration.ofSeconds(-1) succeeds, the negative delay remains present
and orElseGet(...) never runs.

What the skill missed

The miss is both semantic analysis and skill activation. The Optional's
presence means "authoritative retry delay", not merely "numeric header".
Therefore the parser must exclude values that cannot safely drive the present
branch. The existing Optionals guidance covers lazy fallback but does not
explicitly teach filtering a syntactically present, semantically invalid value
into absence before fallback.

Behavior-equivalence analysis

The correction intentionally changes only negative numeric values:

• a negative header now becomes absent and invokes the existing lazy
  exponential fallback;
• zero remains a valid non-negative retry hint;
• positive values remain authoritative and retain their exact duration;
• malformed values continue to use fallback;
• exponential backoff remains lazy and is not computed for valid headers.

This behavior change is safe and required because a negative delay previously
caused an immediate retry, contrary to the product's backoff contract.

Maintainer-preferred code

private static Optional<Duration> parseRetryAfter(String value) {
    try {
        return Optional.of(Duration.ofSeconds(Long.parseLong(value)))
                .filter(duration -> !duration.isNegative());
    } catch (NumberFormatException e) {
        return Optional.empty();
    }
}

The owning selection remains:

return retryAfter.orElseGet(() -> exponentialBackoffWithJitter(config, attempt));

Why the replacement is better

The Optional now represents the domain truth that a usable retry hint is
present. filter(...) keeps validation at the value-producing boundary, and
orElseGet(...) continues to express the lazy fallback without a null,
presence-read, clamp, or duplicated branch.

Desired eval behavior

• Reward checking the semantic validity of a present value before it suppresses
  fallback work.
• Reward filter(...) when an invalid parsed value should behave as absence.
• Reward keeping the non-trivial fallback lazy with orElseGet(...).
• Reward tests for invalid, absent/fallback, and valid/present paths.
• Reward triggering the Optionals skill during the original retry-selection
  implementation even when the prompt does not name Optional.
• Reward explaining the intentional behavior change instead of calling it a
  purely stylistic refactor.

Anti-patterns the eval should reject

• Treating successful parsing as sufficient domain validity.
• Clamping a negative retry hint to zero, which still creates a hot retry.
• Calling orElse(exponentialBackoffWithJitter(...)) and eagerly computing
  fallback for valid headers.
• Converting the Optional to null and branching.
• Using isPresent() followed by get() for this ordinary value flow.
• Filtering after the fallback has already been selected.

Suggested eval name

filter-invalid-retry-hint-before-lazy-fallback