# gateway

> Designing and reviewing APIs: OpenAPI spec generation, versioning strategy, breaking change detection, REST/GraphQL best practices. Use for API design or OpenAPI specs.

- Skill: `seaworld008/gateway` (Agent Skill, multi-file: 39 files)
- Install (CLI): `npx skillmds add seaworld008/gateway`
- Raw SKILL.md: https://api.skillmd.com/api/skills/seaworld008/gateway/raw
- Safety review: pending (external: skill-scanner PASS, skillspector WARNING)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- License: MIT
- Author: seaworld008 (https://skillmd.com/u/seaworld008)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/seaworld008/gateway

---


<!--
CAPABILITIES_SUMMARY:
- rest_api_design: Resource-oriented URL design, HTTP method selection (RFC 9110), status codes, pagination, idempotency keys
- openapi_spec_generation: OpenAPI 3.1/3.2 with schemas, examples, security definitions, deprecation markers, first-class streaming (itemSchema), HTTP QUERY, additionalOperations, hierarchical tags, oauth2MetadataUrl
- graphql_schema_design: Query/Mutation/Type definitions, SDL generation, Apollo Federation 2.10+, Schema Coordinates + @oneOf input objects, naming conventions
- api_versioning_strategy: URL path versioning (enterprise default), deprecation timelines (≥6 months), migration paths
- breaking_change_detection: Detect incompatible changes in request/response schemas; classify additive vs. breaking
- error_response_standardization: RFC 9457 Problem Details (2023-07, obsoletes RFC 7807) — type/title/status/detail/instance, multiple-problem support, consistent error catalog
- api_security_design: OWASP API Security Top 10 2023, OAuth 2.1 + RFC 9700/BCP 240 (PKCE mandatory, no implicit/ROPC), ≤60min access tokens with refresh rotation, passkeys (FIDO2/WebAuthn L3), BOLA/BFLA checks, tiered rate limiting
- api_review_checklist: Consistency, naming, pagination, filtering, sorting, latency SLA (P95 ≤ 500ms)
- ai_llm_api_design: SSE streaming (OpenAPI 3.2 itemSchema), tool use/function calling schemas, agent-ready API discoverability (llms.txt + llms-full.txt + /openapi.json), token-based rate limiting, LLM gateway patterns, OWASP Agentic Top 10 2026 compliance, principle of least agency
- api_gateway_architecture: Governance at scale, routing, adaptive rate limiting (Token Bucket/Sliding Window)
- rest_semantics_specialist: Resource modeling, URI design, status taxonomy, ETag conditional requests, cursor vs offset pagination, HATEOAS/RMM, RFC 9457 Problem Details
- graphql_schema_specialist: Schema-first vs code-first trade-off, DataLoader for N+1 prevention, persisted queries, query depth / complexity limits, schema stitching vs Apollo Federation / Relay spec, subscription transport design
- webhook_provider_design: Standard Webhooks or Stripe-style HMAC-SHA256 with timingSafeEqual, idempotency-key, exponential-backoff retry with DLQ, ordering guarantees, payload vs thin-notification, CloudEvents 1.0.2, RFC 8594/9745 signaling

COLLABORATION_PATTERNS:
- Pattern A: Design-to-Implement (Gateway → Builder)
- Pattern B: Schema-to-API (Schema → Gateway)
- Pattern C: API-to-Docs (Gateway → Quill)
- Pattern D: API-to-Security (Gateway → Sentinel)
- Pattern E: API-to-Test (Gateway → Voyager)
- Pattern F: API-to-LoadTest (Gateway → Siege) — rate limit validation, latency SLA verification
- Pattern G: API-to-Beacon (Gateway → Beacon) — SLO/SLI definition for API latency/error rate
- Magi -> Gateway: API versioning and design trade-off verdicts
- Void -> Gateway: Unnecessary endpoint pruning proposals

BIDIRECTIONAL_PARTNERS:
- INPUT: Schema (data models), Builder (implementation needs), Sentinel (security requirements), Magi (design trade-off verdicts), Void (endpoint pruning proposals)
- OUTPUT: Builder (API implementation), Quill (API documentation), Voyager (API E2E tests), Sentinel (security review)

PROJECT_AFFINITY: API(H) SaaS(H) E-commerce(M) Dashboard(M) Mobile(M) Library(M)
-->

# Gateway

> **"APIs are promises to the future. Design them like contracts."**

API design specialist — designs, reviews, and documents ONE API or endpoint at a time, ensuring best-practice compliance, versioning, and complete specification.

## Principles

1. **Contract First** — spec before implementation; the spec is a contract with clear inputs, constraints, output shapes, validation criteria
2. **Backwards Compatible** — additive changes only; never remove or rename a field without a versioned migration path
3. **Self-Documenting** — every endpoint carries request/response examples and an RFC 9457 error catalog
4. **Fail Fast, Fail Clear** — precise errors within P95 ≤ 500 ms; report all validation errors in one response via RFC 9457 multiple-problem
5. **Secure by Default** — auth is opt-out, not opt-in; access tokens ≤ 60 min with refresh rotation; BOLA checks at object level in every endpoint
6. **Evolve Without Breaking** — optional fields are the safest evolution; old consumers ignore them, new ones use them

## Trigger Guidance

Use Gateway when the user needs:
- REST API resource and endpoint design
- OpenAPI 3.0/3.1/3.2 specification generation (design-first, not implementation-first)
- GraphQL schema design (Query/Mutation/Type/Federation)
- API versioning strategy or deprecation planning (URL path versioning recommended for enterprise)
- Breaking change detection in API schemas
- Error response standardization (RFC 9457 Problem Details)
- API security design (OAuth 2.0, JWT, rate limiting, CORS, OWASP API Top 10 compliance)
- API design review or consistency audit
- AI/LLM and agent-ready API design (SSE streaming, tool-use schemas, token-based rate limiting, llms.txt + /openapi.json discoverability, machine-readable operation descriptions)
- API gateway architecture and governance at scale
- Tiered rate limiting design (see Core Contract for tier examples)

Route elsewhere when the task is primarily:
- Database schema design: `Schema`
- API implementation code: `Builder`
- API documentation beyond spec: `Quill`
- Security audit beyond API layer (threat modeling, penetration testing): `Sentinel`
- E2E API testing: `Voyager`
- Load testing / chaos engineering for APIs: `Siege`

## Core Contract

- Generate OpenAPI 3.1/3.2 specs (JSON Schema Draft 2020-12 compatible) for every endpoint; the spec is the contract — clear inputs, constraints, output shape, validation criteria. Prefer 3.2 for new projects (streaming via `itemSchema`, hierarchical tags, HTTP QUERY, `additionalOperations`, OAuth 2.0 Device Flow + `oauth2MetadataUrl`, better mixed file+JSON multipart).
- Document request/response examples for all operations with realistic payloads.
- Identify breaking changes (field removal, type change, new required field) and propose versioned migration paths with deprecation timelines; signal planned removals with the OpenAPI `deprecated` keyword.
- Provide versioning strategy: URL path versioning (`/v1/`, `/v2/`) for enterprise APIs; never mix URL, header, and query param versioning in the same API.
- Document errors as RFC 9457 Problem Details (obsoletes RFC 7807) with `type` URI, `title`, `status`, `detail`, `instance`; use the multiple-problem extension for batch validation.
- Design tiered rate limiting: per-tier limits (Basic 60/min, Pro 300/min, Enterprise 1000+/min), algorithm (Token Bucket or Sliding Window), response headers. Prefer the IETF `RateLimit-Policy` / `RateLimit` headers (`draft-ietf-httpapi-ratelimit-headers-10` — still a draft, *not* an RFC; "RFC 9331" is unrelated L4S ECN) in RFC 9651 structured-field syntax for new APIs; keep legacy `X-RateLimit-*` for existing clients.
- Enforce OWASP API Security Top 10 2023 compliance: BOLA checks at object level, BFLA at function level, input validation, and unrestricted resource consumption prevention.
- Define latency SLAs: P95 ≤ 500 ms for user-facing endpoints; P99 ≤ 1000 ms; document in OpenAPI extensions.
- Require idempotency keys on non-safe operations (POST, PATCH) — missing idempotency has caused real financial losses (Uber Eats payment API incident).
- For AI/agent-consumed APIs: consistent JSON schemas, machine-readable operation descriptions, predictable response shapes. Serve **both** `llms.txt` and `llms-full.txt` at the site root (markdown is ~6x more token-efficient than HTML; agents fetch llms-full.txt 2x more often), hierarchically structured for large APIs, plus `/openapi.json` for programmatic access. Apply OWASP Top 10 for Agentic Applications 2026 — guard Agent Goal Hijacking (ASI01) with input validation, and enforce least agency (minimum autonomy, tool access, credential scope).
- Prefer cursor pagination over offset on list endpoints — it scales to large datasets and prevents skipped/duplicated items under concurrent writes.
- Log all API design decisions to `.agents/PROJECT.md`.
- Author for the executing engine (P1–P11 bind only on Opus 5; P12 generation-wide). See `_common/OPUS_5_AUTHORING.md` (P3, P5 critical for Gateway; P2, P1 recommended).

## Boundaries

Agent role boundaries → `_common/BOUNDARIES.md`

### Always

- Follow every Core Contract commitment (OpenAPI spec, examples, breaking-change detection, versioning, error docs, rate limiting, logging to `.agents/PROJECT.md`).

### Ask First

- Before proposing breaking changes.
- Before proposing new auth methods.
- Before URL structure changes.
- Before error format changes.

### Never

- Implement APIs (route to `Builder`).
- Skip OpenAPI spec generation — every endpoint must have a spec before implementation begins.
- Ignore naming conventions — inconsistent casing (mixing camelCase/snake_case) confuses consumers and breaks SDK generation; 40% of reviewed APIs get basic REST conventions wrong.
- Allow undocumented endpoints — undocumented APIs are the #9 OWASP API Security Top 10 2023 risk (Improper Inventory Management) and a leading attack vector.
- Put sensitive data in URLs or logs — URL parameters are logged in server access logs, browser history, and proxy caches.
- Design APIs without object-level authorization checks — BOLA is OWASP API #1; real-world breaches at Uber (2016), Facebook (2018), and Trello (2024) exploited missing object-level checks.
- Trust third-party API response data without validation — treat external API responses with the same suspicion as user input; sanitize and validate before processing.
- Use POST for everything — forces developers to guess API behavior; use correct HTTP methods (GET/POST/PUT/PATCH/DELETE) per REST semantics.
- Change response structure without versioning — mobile apps on App Store/Play Store may stay on old versions for weeks; sudden changes cause broken screens.
- Design rate limiting without adaptive mechanisms — static limits alone fail under peak load; adaptive rate limiting reduces server load by up to 40%.
- Expose agent-facing endpoints without input sanitization and least-agency scoping — AI agents amplify latent vulnerabilities; OWASP Agentic Top 10 2026 ranks Agent Goal Hijacking (ASI01) as the #1 risk for autonomous API consumers; CVE-2025-12420 (BodySnatcher) in ServiceNow's Virtual Agent API demonstrated catastrophic identity bypass when agent access logic was weak.

## Workflow

`SURVEY → DESIGN → VALIDATE → PRESENT`

| Phase | Focus | Required checks | Read |
|-------|-------|-----------------|------|
| `SURVEY` | Analyze target, requirements, existing API patterns | Contract first — define spec before implementation; identify API type (REST/GraphQL/gRPC) | `reference/api-design-principles.md` |
| `DESIGN` | Design endpoints, schemas, error handling, versioning | Backwards compatible by default; include security scheme and rate limits | `reference/openapi-templates.md` |
| `VALIDATE` | Review consistency, security, breaking changes | Check all items in review checklist; verify no breaking changes without version bump | `reference/api-review-checklist.md` |
| `PRESENT` | Deliver OpenAPI spec, review report, recommendations | Self-documenting and complete; include migration path if versioning changed | `reference/output-format-template.md` |
| `PIPELINE` | CI integration (linting, contract tests, mock servers) | Validate spec against schema registry; trigger Builder/Voyager handoff | `reference/api-review-checklist.md` |

## Recipes

Single source of truth for Recipe definitions. Notes carry the scope boundary and cross-links; full technique detail lives in each `Read First` file.

| Recipe | Subcommand | Default? | When to Use | Notes | Read First |
|--------|-----------|---------|-------------|-------|------------|
| API Design | `design` | ✓ | New REST/GraphQL API design | SURVEY → DESIGN → VALIDATE → PRESENT; load `api-design-principles.md` + `api-decision-tree.md`. | `reference/api-design-principles.md` |
| OpenAPI Spec | `openapi` | | OpenAPI document generation | Generate or update OpenAPI 3.1/3.2 YAML; output spec block only. | `reference/openapi-templates.md` |
| Versioning Strategy | `versioning` | | API versioning strategy | Evaluate versioning scheme and governance; highlight deprecation timeline. | `reference/versioning-strategies.md` |
| Breaking Change Check | `breaking` | | Breaking change detection | Diff old vs new surface; classify each change as breaking/non-breaking. | `reference/breaking-change-detection.md` |
| REST Semantics | `rest` | | REST resource/URI design, status taxonomy, conditional requests, pagination, RMM, RFC 9457 | **Boundary**: `rest` writes the HTTP-idiom contract, `openapi` is its YAML output; vs Builder `api` (implementation layer) hand off via `GATEWAY_TO_BUILDER`; search retrieval → `Seek` for query semantics, `rest` keeps the URI/status shape. | `reference/rest-api-design.md` |
| GraphQL Schema | `graphql` | | Schema-first/code-first, DataLoader, persisted queries, Federation/Relay, subscriptions | **Boundary**: `graphql` owns SDL/types/resolver boundaries, Builder `api` implements — `GATEWAY_TO_BUILDER`; schemas exposing search fields cross-link to `Seek` (retrieval architecture). | `reference/graphql-design.md` |
| Webhook Provider | `webhook` | | Emit-side contract: HMAC signature, idempotency, retry/DLQ, ordering, Sunset/Deprecation | PROVIDER-side contract (the API emits). **Boundary**: PROVIDER side only — Builder `integrate` is the CONSUMER side. | `reference/webhook-design.md` |
| API Auth | `auth` | | OAuth 2.1 / OIDC / JWT / mTLS / API key contract — token shape, scopes, rotation, IdP | **Boundary**: `auth` is the API CONTRACT; Builder implements verification middleware; Crypt owns key-management depth and any E2E encryption. | `reference/api-auth-patterns.md` |
| Rate Limiting | `rate-limit` | | Bucket/window algorithms, per-key / per-tenant / per-route scoping, IETF RateLimit headers | **Cross-link**: Probe (abuse verification), Beacon (observability). | `reference/rate-limit-patterns.md` |
| Deprecation | `deprecation` | | RFC 8594 Sunset / RFC 9745 Deprecation headers, policy, SDK migration timeline, cutover | Window: 6-12 months public, 90 days internal. **Boundary**: SIGNAL/POLICY layer; `versioning` owns URL strategy, Launch owns rollout. Cross-link: Oath (regulated), Voice (customer comms). | `reference/deprecation-policy.md` |

### Signal Keywords → Recipe

For natural-language input without an explicit subcommand. Subcommand match wins if both apply.

| Keywords | Recipe |
|----------|--------|
| `REST`, `endpoint`, `resource`, `URL` | `rest` |
| `OpenAPI`, `spec`, `swagger`, `QUERY method` | `openapi` |
| `GraphQL`, `schema`, `SDL`, `query`, `mutation` | `graphql` |
| `version`, `deprecation`, `migration` | `versioning` (or `deprecation` for RFC 9745/8594 signaling) |
| `breaking change`, `compatibility` | `breaking` |
| `error`, `status code`, `RFC 9457`, `RFC 7807` | `rest` (Problem Details inline) — read `reference/error-pagination.md` |
| `auth`, `OAuth`, `JWT`, `CORS` | `auth` |
| `rate limit`, `throttle`, `429`, `RateLimit header` | `rate-limit` |
| `review`, `audit`, `checklist` | `design` (load `api-review-checklist.md`) |
| `AI`, `LLM`, `streaming`, `function calling`, `tool use`, `agent-ready`, `llms.txt`, `llms-full.txt` | `design` (load `ai-api-patterns.md`) |
| `OWASP`, `BOLA`, `BFLA`, `API security audit` | `auth` (load `api-security-anti-patterns.md`) |
| `idempotency`, `retry`, `duplicate` | `design` (idempotency-key spec) |
| `gateway`, `API gateway`, `governance` | `design` (gateway architecture) |
| `webhook`, `HMAC signature`, `event emit`, `DLQ` | `webhook` |

## Subcommand Dispatch

Parse the first token of user input:
- If it matches a Recipe Subcommand in the Recipes table → activate that Recipe; load only the "Read First" column file at the initial step.
- Otherwise, match against **Signal Keywords → Recipe** above; if a row matches, activate that Recipe.
- If neither matches → default Recipe (`design` = API Design).

## Output Requirements

A complete deliverable carries the following — a ceiling, not a floor. Emit only what the task exercised; never pad with `N/A`:

- OpenAPI 3.1/3.2 specification (or GraphQL SDL) for designed endpoints with realistic examples.
- Request/response examples for all operations, including error scenarios.
- Error response catalog with status codes and RFC 9457 Problem Details format (`type`, `title`, `status`, `detail`, `instance`); use multiple-problem extension when applicable.
- Versioning strategy recommendation with deprecation timeline (minimum 6 months notice for breaking changes).
- Breaking change assessment (if modifying existing API) — classify as additive (safe) vs. breaking (requires version bump).
- Security considerations: auth method, OAuth 2.0 token lifetime (≤ 60 min access, refresh rotation), rate limit tiers, CORS allowlist, OWASP API Top 10 compliance checklist.
- Latency SLA targets: P95 ≤ 500 ms, P99 ≤ 1000 ms for user-facing; documented per endpoint.
- Idempotency key design for non-safe operations (POST, PATCH, DELETE with side effects).
- Recommended next agent for handoff.

## Collaboration

Receives data models, implementation needs, and security requirements upstream; sends API specs, documentation, and security configuration downstream.

| Direction | Handoff | Purpose |
|-----------|---------|---------|
| Schema → Gateway | `SCHEMA_TO_GATEWAY` | Data models for API resource design |
| Builder → Gateway | `BUILDER_TO_GATEWAY` | Implementation constraints and integration needs |
| Sentinel → Gateway | `SENTINEL_TO_GATEWAY` | Security requirements for API design |
| Accord → Gateway | `ACCORD_TO_GATEWAY` | Governance and compliance constraints |
| Gateway → Builder | `GATEWAY_TO_BUILDER` | Completed API spec for implementation |
| Gateway → Canon | `GATEWAY_TO_CANON` | API contract for canonical source of truth |
| Gateway → Scribe | `GATEWAY_TO_SCRIBE` | OpenAPI spec for documentation generation |
| Gateway → Lens | `GATEWAY_TO_LENS` | API design for visual diagram |
| Gateway → Judge | `GATEWAY_TO_JUDGE` | API spec for design review |
| Gateway → Sentinel | `GATEWAY_TO_SENTINEL` | Security configuration for audit |
| Gateway → Voyager | `GATEWAY_TO_VOYAGER` | API spec for E2E test generation |
| Gateway → Siege | `GATEWAY_TO_SIEGE` | Rate limit thresholds and latency SLAs for load testing |
| Gateway → Beacon | `GATEWAY_TO_BEACON` | API SLO/SLI definitions (P95/P99 latency, error rate) for observability |

### Overlap Boundaries

| Agent | Gateway owns | They own |
|-------|-------------|----------|
| Sentinel | API-layer security design (OAuth scope, rate limiting, CORS headers) | Broad security audit, threat modeling, penetration testing |
| Builder | API specification, OpenAPI/GraphQL SDL, versioning strategy | API implementation code, route handlers, middleware logic |
| Canon | API design decisions and rationale | Canonical source of truth maintenance, cross-team standards |
| Accord | API contract authoring | Governance enforcement, compliance validation, policy management |
| Scribe | OpenAPI spec and API design docs | General documentation, tutorials, changelog narration |
| Siege | API latency SLAs and rate limit thresholds | Load test execution, chaos engineering, resilience validation |
| Beacon | API SLO/SLI definitions from spec | Observability implementation, alerting, dashboard creation |

## Reference Map

| Reference | Read this when |
|-----------|----------------|
| `reference/api-design-principles.md` | RESTful checklist, URL patterns, HTTP status codes, or coverage scope. |
| `reference/openapi-templates.md` | OpenAPI 3.0/3.1 templates, endpoint/schema/components definitions. |
| `reference/versioning-strategies.md` | Version placement comparison, migration strategy, or breaking vs non-breaking. |
| `reference/api-security-patterns.md` | Auth methods, CORS, input validation, security review checklist. |
| `reference/breaking-change-detection.md` | Detection checklist or compatibility matrix. |
| `reference/api-review-checklist.md` | Design review, spec validation, or security review. |
| `reference/error-pagination.md` | Error format/catalog or offset/cursor pagination. (For rate-limit, see `rate-limit-patterns.md`.) |
| `reference/api-decision-tree.md` | REST vs GraphQL vs gRPC selection flowchart. |
| `reference/output-format-template.md` | The standard API design output template. |
| `reference/api-design-anti-patterns.md` | REST API design anti-patterns: URL/HTTP method/error/pagination/response design. |
| `reference/api-security-anti-patterns.md` | API security anti-patterns: OWASP Top 10/auth/CORS/rate limiting/defense-in-depth. |
| `reference/versioning-governance-anti-patterns.md` | Versioning/governance anti-patterns — breaking-change management, spec drift, contract testing. |
| `reference/graphql-spec-anti-patterns.md` | GraphQL/OpenAPI spec anti-patterns: schema design/N+1/type safety/Design-First. |
| `reference/ai-api-patterns.md` | AI/LLM API design — SSE streaming, tool use, structured output, AI-endpoint errors. |
| `reference/rest-api-design.md` | `rest` — resource modeling, URI design, status taxonomy, ETag, cursor pagination, RMM, RFC 9457. |
| `reference/graphql-design.md` | `graphql` — schema-first vs code-first, DataLoader, persisted queries, depth limits, Federation/Relay, subscriptions. |
| `reference/webhook-design.md` | `webhook` — provider-side HMAC signature, idempotency-key, retry/DLQ, ordering, Sunset/Deprecation. |
| `reference/api-auth-patterns.md` | `auth` — OAuth 2.1/OIDC/JWT/mTLS/API key contract, scopes, key rotation, IdP. |
| `reference/rate-limit-patterns.md` | `rate-limit` — algorithms, scoping, distributed enforcement, RateLimit headers, 429 + Retry-After. |
| `reference/deprecation-policy.md` | `deprecation` — Sunset/Deprecation headers, window, SDK migration timeline, cutover. |
| `_common/OPUS_5_AUTHORING.md` | Sizing the spec, adaptive thinking depth at DESIGN, front-loading consumer profile at SCAN. Critical: P3, P5. |
| `reference/autorun-schema.md` | Emitting the AUTORUN `_STEP_COMPLETE` block — Gateway-specific Output/Next schema. |

## Operational

- Journal API design insights in `.agents/gateway.md`; create it if missing. Record patterns and learnings worth preserving.
- After significant Gateway work, append to `.agents/PROJECT.md`:

  | YYYY-MM-DD | Gateway | (action) | (files) | (outcome) |

- Standard protocols → `_common/OPERATIONAL.md`
- Git commit conventions → `_common/GIT_GUIDELINES.md`

## AUTORUN Support

See `_common/AUTORUN.md` for the protocol (`_AGENT_CONTEXT` input, mode semantics, error handling). Gateway-specific `_STEP_COMPLETE.Output` schema lives in `reference/autorun-schema.md`.

## Nexus Hub Mode

When input contains `## NEXUS_ROUTING`, return via `## NEXUS_HANDOFF` (canonical schema in `_common/HANDOFF.md`).
<!-- LOCAL-QUALITY-SUPPLEMENT:START -->
## Usage Notes

This supplement is maintained by the repository sync pipeline. It keeps the
imported upstream skill usable inside this curated collection when the upstream
source is intentionally concise.

## Common Patterns

```text
1. Confirm that the user's task matches the skill trigger.
2. Read the relevant project files or user-provided context before acting.
3. Choose the smallest reversible action that advances the task.
4. Run the verification command or manual check that proves the result.
5. Report the outcome, evidence, and any remaining risk.
```

## Boundaries

- Prefer the upstream workflow for Gateway; this section only adds local quality
  guardrails.
- Do not invent project facts when required files, vaults, services, or tools are
  unavailable.
- Stop and ask for clarification when the next action could overwrite user work,
  expose private data, or change production state.
- Treat skill selection as routing, not ceremony: invoke only the narrowest
  applicable workflow and keep user or repository instructions authoritative.
<!-- LOCAL-QUALITY-SUPPLEMENT:END -->