fetcher-integrationlisted

# fetcher-integration ## Workflow 1. Start with `@ahoo-wang/fetcher` before reaching for higher-level packages. 2. Prefer `NamedFetcher` when the client will be reused by decorators, generated clients, or app services. 3. Mutate `FetchExchange` inside interceptors; do not return a replacement exchange from `intercept()`. 4. Use `ResultExtractors` when callers need typed values instead of raw `Response` objects. 5. Load `references/api.md` for exact method signatures, lifecycle order, or full examples. ## Key Practices - Keep interceptors small and phase-specific: request shaping, response validation, and error recovery are separate responsibilities. - Use `urlParams.path` for template variables and `urlParams.query` for query strings. - Use `validateStatus` or `IGNORE_VALIDATE_STATUS` intentionally when non-2xx responses are part of the domain flow. ## References - `references/api.md`: Detailed package API, examples, and edge-case guidance. Load it only when the task needs method signatures, interceptor ordering, URL parameter examples, error hierarchy, and complete service setup examples. ## Related Skills - $fetcher-decorator-service: Use when services should be declared with TypeScript decorators. - $fetcher-openapi-generator: Use when clients should be generated from an OpenAPI document. - $fetcher-cosec-auth: Use when interceptors need CoSec authentication behavior.