#47 docs: fix retry examples that match HTTP status codes as exit codes

Summary

Four examples match HTTP status codes in exit_code: retry_policy with [429, 503] or [429, 503, 504] on a curl step, and continue_on with [503]. A process exit code is 0-255, and curl does not exit with the HTTP status, so these conditions never match. curl -f exits with 22 for any HTTP status of 400 or more.

The examples now run curl -fsS and match curl's own exit codes (7 = connection failed, 22 = HTTP status >= 400, 28 = timeout), like the continue_on example in the error handling page.

Changes

• writing-workflows/execution-control.md: retry with backoff example
• writing-workflows/yaml-specification.md: retry_policy example, and the exit_code row says these are process exit codes, not HTTP status codes
• writing-workflows/examples/reliability.md: smart retry example and its diagram
• writing-workflows/continue-on.md: continue_on with retry example

Related Issues

Related to dagucloud/dagu#3209, which proposes a way to tell HTTP statuses apart in http.request. These fixes do not depend on it.

Checks

• node scripts/validate-examples.mjs with Dagu built from main (0689a90): 912 examples validated
• pnpm build
• pnpm test:worker
• git diff --check
• Ran the retry example against a closed port with Dagu main: the step retried on exit code 7, then continue_on let the next step run.

---

Summary by cubic

Fixes retry examples that matched HTTP status codes as exit_code values, which could never trigger since process exit codes are 0-255 and curl doesn't exit with the HTTP status.

The examples now run curl -fsS and match curl's own exit codes (7 = connection failed, 22 = HTTP status >= 400, 28 = timeout). The exit_code table row in writing-workflows/yaml-specification.md now states these are process exit codes, not HTTP status codes.