# Pattern: fetch-retry-bypass

Apply on every toolkit / Method fetch failure. Domains only mark evidence
**hard** vs **soft**; this pattern decides retry and bypass.

## Classify

| Class | Signals | Action |
|-------|---------|--------|
| `retryable` | timeout, connection reset, 5xx, rate limit, temporary unavailable | Bounded retry: up to **2** extra attempts with short delay; then hard/soft |
| `non_retryable` | auth failure, illegal params, unsupported GK/plane, explicit business reject | **No** retry; hard/soft immediately |
| `not_found_signal` | not found and Procedure treats absence as a signal | **No** retry; write `result`; continue normal judgment |
| `ambiguous` | cannot classify | Try once as retryable; still fail → non_retryable path |

## Hard vs soft after exhausted / non-retryable

| Role | Meaning | After failure |
|------|---------|---------------|
| `hard` | Gate, Health checklist required item, or sole branch criterion | May fetch other soft/bypass paths for context; mark step failed; **forbid** `healthy`; **forbid** strong `root_cause` from this gap alone; final at least `uncertain` |
| `soft` | Confidence boost / optional detail | Bypass as missing; continue; lower confidence; list in Evidence index |

Defaults: Health checklist items and cross-domain Gate evidence are **hard**.
Events/detail deepening and optional side evidence are **soft** unless the
SUBSKILL overrides.

## Trace

On failure, put in `result` / judgment reason: class, retry count, hard/soft,
action (`retried` / `bypassed` / `blocked`).

## Method boundary

Method/toolkit returns the error. This pattern + Procedure hard/soft decide
retry / bypass / healthy eligibility.