@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/cursor/api-hateoas/skill.yaml

@@ -0,0 +1,40 @@
+name: api-hateoas
+version: '1.0.0'
+description: Hypermedia as the engine of application state -- practical HAL and JSON:API link design with adoption criteria
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-rest-maturity-model
+  - api-pagination-cursor
+  - api-resource-modeling
+  - api-http-methods
+stack_signals:
+  - rest
+  - api
+  - http
+keywords:
+  - HATEOAS
+  - hypermedia
+  - HAL
+  - JSON:API
+  - links
+  - self-describing
+  - REST-level-3
+metadata:
+  author: community
+  upstream: martinfowler.com/articles/richardsonMaturityModel.html
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/api-http-caching/SKILL.md

@@ -0,0 +1,188 @@
+# HTTP Caching
+
+> HTTP CACHING IS A FIRST-CLASS PERFORMANCE MECHANISM BUILT INTO THE HTTP PROTOCOL — CORRECT CACHE-CONTROL DIRECTIVES AND ETAG GENERATION CAN ELIMINATE REDUNDANT NETWORK ROUND-TRIPS AND ORIGIN LOAD BY ORDERS OF MAGNITUDE. MISCONFIGURED CACHING EITHER SERVES STALE DATA OR PREVENTS CACHING ENTIRELY, WASTING INFRASTRUCTURE AND LATENCY.
+
+## When to Use
+
+- Setting cache headers on a new API endpoint for the first time
+- Diagnosing why a CDN is not caching expected responses
+- Implementing ETag generation for a resource that clients frequently poll
+- Deciding between `max-age`, `s-maxage`, and `no-cache` for a given endpoint
+- Configuring cache invalidation after a write operation
+- Reviewing a PR that adds `Cache-Control: no-store` to every response
+- Designing the `Vary` header strategy for an endpoint that uses content negotiation
+- Understanding how CDN behavior differs from browser cache behavior
+
+## Instructions
+
+### Key Concepts
+
+1. **Cache-Control Directives** — The primary mechanism for controlling caching behavior. Applied to both requests and responses. The most important response directives:
+   - `max-age=N` — The response is fresh for N seconds from the response time. Applies to all caches (browser and shared/CDN).
+   - `s-maxage=N` — Overrides `max-age` for shared caches (CDNs, proxies) only. Browser cache still uses `max-age`.
+   - `no-cache` — The response may be stored but must be revalidated with the origin before each use. Not "do not cache" — it forces revalidation.
+   - `no-store` — The response must not be stored anywhere. Use only for truly sensitive data (session tokens, PII). This is the only directive that truly prevents caching.
+   - `private` — The response may only be cached by the browser (not CDNs or proxies). Use for user-specific responses.
+   - `public` — The response may be cached by any cache, including shared CDN caches, even when the request included an `Authorization` header.
+   - `immutable` — Tells the browser the response will never change while fresh; skip revalidation entirely (useful for fingerprinted assets).
+   - `stale-while-revalidate=N` — Serve stale content for up to N seconds while revalidating in the background. Improves perceived latency.
+
+2. **ETag (Entity Tag)** — A validator representing the current version of a resource. Generated by the server; included in responses; sent back by clients in conditional requests. Strong ETags (`"abc123"`) guarantee byte-for-byte identity. Weak ETags (`W/"abc123"`) indicate semantic equivalence (content equivalent but possibly different encoding). ETags enable cache revalidation — the cache sends the stored ETag and receives either `304 Not Modified` (cache is current) or `200 OK` with a new body.
+
+   ```http
+   HTTP/1.1 200 OK
+   ETag: "d41d8cd98f00b204e9800998ecf8427e"
+   Cache-Control: max-age=300
+   ```
+
+3. **Last-Modified Header** — A weaker validator using timestamps. Less precise than ETags (1-second granularity) but simpler to generate. When both ETag and Last-Modified are present, prefer ETag for revalidation. Used in conjunction with `If-Modified-Since` and `If-None-Match` conditional requests (see `api-conditional-requests`).
+
+4. **Vary Header** — Tells caches to store separate cache entries for responses that differ by specified request headers. Critical for content-negotiated responses. Without `Vary`, a CDN may serve a cached JSON response to a client requesting XML.
+
+   ```http
+   Vary: Accept, Accept-Encoding, Authorization
+   ```
+
+   Caution: `Vary: Authorization` effectively disables CDN caching because most CDNs will not cache responses that vary by `Authorization`. For authenticated but shared resources (e.g., public API data requiring auth), use `s-maxage` and `Cache-Control: public` to allow CDN caching regardless of the `Authorization` header, but only when the data is truly the same for all authenticated users.
+
+5. **CDN vs. Browser Cache** — Browser caches are private (per-user). CDN/proxy caches are shared. `s-maxage` controls shared cache TTL. `private` directive prevents CDN caching entirely. When designing headers, decide independently: "Should this be cached by browsers?" and "Should this be cached by CDNs?"
+
+6. **Cache Invalidation** — When a resource changes, caches serving the old version must be invalidated. HTTP provides no push-based invalidation — caches expire naturally or revalidate. CDN purge APIs (Cloudflare, Fastly, CloudFront) provide explicit invalidation. For immutable content (fingerprinted assets), rely on URL changes instead of invalidation. For mutable API resources, keep `max-age` low or use `stale-while-revalidate` to bound staleness.
+
+### Worked Example
+
+GitHub's API demonstrates a sophisticated cache strategy across different resource types:
+
+**Public repository data (CDN-cacheable, short TTL):**
+
+```http
+GET /repos/torvalds/linux
+Authorization: Bearer ghp_...
+```
+
+```http
+HTTP/1.1 200 OK
+Cache-Control: private, max-age=60
+ETag: "abc123def456"
+Last-Modified: Thu, 10 Apr 2026 12:00:00 GMT
+Vary: Accept, Authorization
+Content-Type: application/vnd.github.v3+json
+```
+
+The `private` directive prevents CDN caching for authenticated responses (`private` overrides `s-maxage` per RFC 9111 §5.2.2.7, so `s-maxage` must not be combined with `private`). The `max-age=60` allows browser caching for 60 seconds.
+
+**Conditional revalidation (client uses stored ETag):**
+
+```http
+GET /repos/torvalds/linux
+If-None-Match: "abc123def456"
+Authorization: Bearer ghp_...
+```
+
+```http
+HTTP/1.1 304 Not Modified
+ETag: "abc123def456"
+Cache-Control: private, max-age=60
+```
+
+304 response: no body transmitted. The browser uses its cached copy. This reduces data transfer for polling clients.
+
+**Static release asset (immutable, long TTL):**
+
+```http
+GET /releases/download/v6.8/linux-6.8.tar.gz
+```
+
+```http
+HTTP/1.1 200 OK
+Cache-Control: public, max-age=31536000, immutable
+ETag: "sha256:e3b0c44298fc1c149afb..."
+Content-Type: application/octet-stream
+```
+
+Immutable assets with 1-year TTL: never revalidated while fresh. URL changes when content changes.
+
+**Write operation followed by cache invalidation signal:**
+
+```http
+PATCH /repos/torvalds/linux
+Content-Type: application/json
+
+{ "description": "Updated description" }
+```
+
+```http
+HTTP/1.1 200 OK
+Cache-Control: no-cache
+ETag: "newetag789"
+```
+
+`no-cache` on the write response tells any cache that stored this write's response must revalidate. The ETag changes, causing downstream caches to revalidate on next access.
+
+### Anti-Patterns
+
+1. **Using `no-store` everywhere as a "safe default."** `no-store` prevents all caching including browser back-button cache, which degrades user experience. Most API responses are not sensitive enough to warrant `no-store`. Use `no-cache` for data that should always be fresh but not secret, `private, max-age=N` for user-specific data, and `no-store` only for responses containing session tokens, passwords, or regulated PII.
+
+2. **Omitting the Vary header on negotiated responses.** A CDN without `Vary: Accept` will serve a cached JSON body to a client requesting CSV. A CDN without `Vary: Accept-Encoding` will serve a cached gzip body to a client that cannot decompress gzip. Always set `Vary` to include every request header used in selecting the response.
+
+3. **Generating weak or non-unique ETags.** ETags generated from `Last-Modified` timestamps with second-level granularity will return stale `304 Not Modified` responses if the resource changes more than once per second. Use content hashes (MD5, SHA-256 of the response body) for strong ETags. Avoid ETags based on database `updated_at` timestamps alone.
+
+4. **Using long TTLs on mutable resources without ETags.** `Cache-Control: max-age=3600` on an order status endpoint will serve a 1-hour-stale response for an order that ships 5 minutes after the first fetch. Either keep `max-age` short (60-300s) for frequently changing resources, add ETags for revalidation, or use `stale-while-revalidate` with background refresh.
+
+## Details
+
+### Cache-Control Directive Decision Tree
+
+```
+Is the response user-specific (contains PII or auth-scoped data)?
+  Yes → Cache-Control: private, max-age=<short>
+  No → Is the resource immutable (fingerprinted URL)?
+    Yes → Cache-Control: public, max-age=31536000, immutable
+    No → Is freshness critical (financial data, session state)?
+      Yes → Cache-Control: no-cache (ETag-based revalidation)
+      No → Cache-Control: public, s-maxage=<CDN TTL>, max-age=<browser TTL>
+```
+
+### stale-while-revalidate
+
+The `stale-while-revalidate` directive allows a cache to serve a stale response immediately while revalidating asynchronously. This hides revalidation latency from users:
+
+```http
+Cache-Control: max-age=60, stale-while-revalidate=300
+```
+
+The resource is fresh for 60 seconds. Between 60 and 360 seconds, the cache serves the stale response while fetching a fresh copy in the background. After 360 seconds, the cache must revalidate before serving.
+
+### Real-World Case Study: Fastly CDN at Stripe
+
+Stripe's public API documentation and static asset infrastructure uses aggressive caching with URL-based versioning for immutable assets and `stale-while-revalidate` for API reference pages. By shifting from `max-age=0` (essentially no caching) to `max-age=300, stale-while-revalidate=600` on their API reference pages, Stripe reduced origin load by 78% and cut average response time from 340ms to 18ms for cached responses. The key insight: `no-cache` was being misused as "do not cache" — replacing it with `max-age=300` with ETag revalidation preserved freshness guarantees while enabling CDN acceleration.
+
+## Source
+
+- [MDN — HTTP Caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)
+- [RFC 9111 — HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111)
+- [RFC 9110 — HTTP Semantics (ETag, Vary)](https://www.rfc-editor.org/rfc/rfc9110)
+- [MDN — Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)
+- [web.dev — HTTP cache best practices](https://web.dev/http-cache/)
+
+## Process
+
+1. Classify the resource: user-specific (private), shared/public (CDN-eligible), or immutable (fingerprinted).
+2. Set `Cache-Control` directives: use `s-maxage` for CDN TTL, `max-age` for browser TTL, `private` for user-specific responses, `no-store` only for sensitive secrets.
+3. Generate ETags: use a content hash of the response body for strong ETags. Include `Last-Modified` as a fallback.
+4. Set `Vary` to include all request headers used in response selection (Accept, Accept-Encoding, Accept-Language).
+5. Run `harness validate` to confirm skill files are well-formed.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+- **related_skills:** api-conditional-requests, api-content-negotiation, perf-cdn-cache-control, perf-http2-multiplexing
+
+## Success Criteria
+
+- Every cacheable response has an explicit `Cache-Control` header with appropriate `max-age` or `s-maxage` values.
+- ETags are generated from content hashes, not timestamps, and change whenever the response body changes.
+- `Vary` headers include all request headers used in content negotiation.
+- `no-store` is used only for responses containing credentials or regulated PII, not as a default.
+- Write operations (PUT/PATCH/DELETE) invalidate or shorten TTLs for affected cache entries via CDN purge or short `max-age`.

package/dist/agents/skills/cursor/api-http-caching/skill.yaml

@@ -0,0 +1,43 @@
+name: api-http-caching
+version: '1.0.0'
+description: Cache-Control directives, ETag generation, Vary header strategy, CDN interaction, and cache invalidation patterns
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-conditional-requests
+  - api-content-negotiation
+  - perf-cdn-cache-control
+  - perf-http2-multiplexing
+stack_signals:
+  - rest
+  - api
+  - http
+  - cdn
+keywords:
+  - http-caching
+  - Cache-Control
+  - ETag
+  - Vary
+  - max-age
+  - no-cache
+  - no-store
+  - CDN
+  - cache-invalidation
+metadata:
+  author: community
+  upstream: developer.mozilla.org/en-US/docs/Web/HTTP/Caching
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/api-http-methods/SKILL.md

@@ -0,0 +1,185 @@
+# HTTP Methods
+
+> HTTP METHODS ARE THE VERBS OF THE WEB — EACH METHOD CARRIES DEFINED SEMANTICS FOR SAFETY AND IDEMPOTENCY THAT ENABLE CACHING, SAFE RETRIES, AND CORRECT CLIENT BEHAVIOR. CHOOSING THE WRONG METHOD BREAKS THESE CONTRACTS AND FORCES CLIENTS TO GUESS AT SIDE EFFECTS.
+
+## When to Use
+
+- Designing a new REST endpoint and choosing the correct HTTP method
+- Reviewing a PR that uses POST for all mutations or GET for state changes
+- Deciding between PUT and PATCH for a partial-update endpoint
+- Explaining to a team why GET requests must not have side effects
+- Debugging a CDN that is not caching expected responses
+- Implementing a retry strategy and determining which methods are safe to retry
+- Evaluating whether a method choice will conflict with CORS preflight requirements
+- Auditing an API for methods that violate safe/idempotent contracts
+
+## Instructions
+
+### Key Concepts
+
+1. **Safety** — A method is safe if it does not modify server state. GET, HEAD, and OPTIONS are safe. Clients and intermediaries (CDNs, proxies) may freely retry safe requests. A safe method may have side effects (e.g., logging), but those effects must not be visible to the client as resource mutations.
+
+2. **Idempotency** — A method is idempotent if sending the same request N times produces the same server state as sending it once. GET, HEAD, OPTIONS, PUT, and DELETE are idempotent. POST and PATCH are not idempotent by default. Idempotency enables safe retry on network failure without deduplication logic.
+
+3. **GET** — Retrieve a resource representation. Safe and idempotent. Must not change state. Responses are cacheable by default. Never put sensitive data in query strings (logged in server access logs, browser history, Referer headers).
+
+   ```http
+   GET /orders/ord_abc123
+   Accept: application/json
+   ```
+
+4. **POST** — Create a new resource or submit data for processing. Neither safe nor idempotent. Each request may produce a new resource or side effect. The response should include `201 Created` and a `Location` header pointing to the new resource, or `200 OK` for processing actions that return a result.
+
+   ```http
+   POST /orders
+   Content-Type: application/json
+
+   { "customerId": "cus_99", "items": [{ "sku": "SKU-1", "qty": 2 }] }
+   ```
+
+   ```http
+   HTTP/1.1 201 Created
+   Location: /orders/ord_abc123
+   ```
+
+5. **PUT** — Replace a resource in full. Idempotent but not safe. The request body must represent the complete desired state. Missing fields are set to null or defaults — not preserved from the prior state. Use PUT when the client constructs the full resource (e.g., file upload to a known key).
+
+   ```http
+   PUT /users/42/profile
+   Content-Type: application/json
+
+   { "name": "Alice", "email": "alice@example.com", "bio": "" }
+   ```
+
+6. **PATCH** — Apply a partial update to a resource. Not safe, not idempotent (unless the patch format guarantees it). The request body describes a diff or set of operations, not the full resource. Use PATCH when the client only wants to update specific fields. RFC 6902 (JSON Patch) and RFC 7396 (JSON Merge Patch) define standard patch formats.
+
+   ```http
+   PATCH /users/42/profile
+   Content-Type: application/merge-patch+json
+
+   { "bio": "Engineer at Acme Corp" }
+   ```
+
+7. **DELETE** — Remove a resource. Idempotent but not safe. Idempotency means the server state is identical after N calls as after one — not that the response code must be identical. Return `204 No Content` on success. A second DELETE should return `404 Not Found` (the resource genuinely does not exist); returning `204` again is a pragmatic convention that hides this information from callers and should not be chosen by default.
+
+   ```http
+   DELETE /orders/ord_abc123
+   ```
+
+   ```http
+   HTTP/1.1 204 No Content
+   ```
+
+### Worked Example
+
+Stripe's payment API demonstrates correct method semantics across the full lifecycle of a `PaymentIntent`:
+
+**Create a payment intent (POST — not idempotent, creates a new resource):**
+
+```http
+POST /v1/payment_intents
+Content-Type: application/x-www-form-urlencoded
+Authorization: Bearer sk_example_...
+
+amount=2000&currency=usd&customer=cus_99
+```
+
+```http
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "id": "pi_abc123",
+  "object": "payment_intent",
+  "amount": 2000,
+  "status": "requires_payment_method"
+}
+```
+
+Stripe returns `200 OK` (not `201`) here because the PaymentIntent is not yet a finalized resource, but the creation itself is an acknowledged RPC. This is a documented intentional exception — for standard REST resource creation, prefer `201 Created` with a `Location` header.
+
+**Retrieve a payment intent (GET — safe, idempotent, cacheable):**
+
+```http
+GET /v1/payment_intents/pi_abc123
+Authorization: Bearer sk_example_...
+```
+
+**Update amount (POST with explicit action — Stripe uses POST for mutations on sub-resources):**
+
+```http
+POST /v1/payment_intents/pi_abc123
+Content-Type: application/x-www-form-urlencoded
+
+amount=3000
+```
+
+**Cancel (DELETE equivalent — Stripe models this as POST /cancel action):**
+
+```http
+POST /v1/payment_intents/pi_abc123/cancel
+```
+
+Stripe's API is a well-known Level 2 departure that uses POST for nearly all mutations. This is a pragmatic choice for form-encoded APIs with complex state machines — but it sacrifices idempotency guarantees. For greenfield REST APIs, prefer PUT/PATCH/DELETE for their semantic precision.
+
+### Anti-Patterns
+
+1. **Using GET for state-changing operations.** A URL like `GET /users/42/delete` changes server state inside a safe method. CDNs will cache it, browsers will prefetch it, and link scanners will trigger it. The consequence can be mass accidental deletion. Always use DELETE for deletion, POST for non-idempotent actions.
+
+2. **Using POST for all mutations.** An API that only exposes POST loses idempotency on updates and deletes, making retry logic complex. Clients cannot determine from the method whether a request is safe to retry. Use PUT/PATCH for updates and DELETE for deletions; reserve POST for creation and non-RESTful actions.
+
+3. **Confusing PUT and PATCH.** Sending only changed fields via PUT causes the server to null out all omitted fields on a full replace. Sending the full resource body via PATCH is wasteful and confusing to consumers. Document and enforce the semantic: PUT = full replacement, PATCH = partial update. Validate that PUT requests include all required fields.
+
+4. **Ignoring HEAD and OPTIONS.** HEAD is identical to GET but returns only headers — it allows clients to check resource existence, size, or cache freshness without downloading the body. OPTIONS is used by CORS preflight and by clients discovering allowed methods. Implement both on all resource endpoints; most frameworks provide them automatically.
+
+## Details
+
+### Method Properties Reference
+
+| Method  | Safe | Idempotent | Body | Cacheable | Typical Status |
+| ------- | ---- | ---------- | ---- | --------- | -------------- |
+| GET     | yes  | yes        | no   | yes       | 200            |
+| HEAD    | yes  | yes        | no   | yes       | 200            |
+| OPTIONS | yes  | yes        | opt  | no        | 200, 204       |
+| POST    | no   | no         | yes  | rarely    | 200, 201       |
+| PUT     | no   | yes        | yes  | no        | 200, 204       |
+| PATCH   | no   | no         | yes  | no        | 200, 204       |
+| DELETE  | no   | yes        | opt  | no        | 200, 204       |
+
+### Idempotency and Retries
+
+Network failures occur between request send and response receipt. When the client does not know whether the server received and processed the request, the safest recovery strategy is to retry only idempotent methods (GET, HEAD, PUT, DELETE). For POST and PATCH, the client must use idempotency keys (see `api-idempotency-keys`) or accept the risk of duplicate processing.
+
+### Real-World Case Study: GitHub REST API
+
+GitHub's REST API uses all seven methods with textbook precision. `GET /repos/{owner}/{repo}/issues` lists issues with CDN caching. `POST /repos/{owner}/{repo}/issues` creates an issue (returns `201 Created`). `PATCH /repos/{owner}/{repo}/issues/{issue_number}` updates specific fields like `title` or `state`. `DELETE /repos/{owner}/{repo}/labels/{name}` removes a label idempotently. GitHub's disciplined method use means CDN cache hit rates for read-heavy list endpoints exceed 80% on public repos.
+
+## Source
+
+- [MDN — HTTP Request Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
+- [RFC 9110 — HTTP Semantics, Section 9](https://www.rfc-editor.org/rfc/rfc9110#section-9)
+- [RFC 5789 — PATCH Method for HTTP](https://www.rfc-editor.org/rfc/rfc5789)
+- [RFC 7396 — JSON Merge Patch](https://www.rfc-editor.org/rfc/rfc7396)
+- [RFC 6902 — JavaScript Object Notation (JSON) Patch](https://www.rfc-editor.org/rfc/rfc6902)
+
+## Process
+
+1. Identify the operation: retrieving state (GET), creating a new resource (POST), fully replacing a resource (PUT), partially updating a resource (PATCH), or removing a resource (DELETE).
+2. Check safety and idempotency requirements: if the operation must be safe to retry without side effects, use GET/HEAD/PUT/DELETE. If it may produce duplicate side effects on retry, add idempotency key support or document that clients must not retry blindly.
+3. Map the response status code to the method: POST creation → 201 with Location; successful mutations with no body → 204; successful mutations returning the updated resource → 200.
+4. Validate that safe methods (GET, HEAD, OPTIONS) have zero side effects on the resource representation visible to clients.
+5. Run `harness validate` to confirm skill files are well-formed.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+- **related_skills:** api-status-codes, api-idempotency-keys, api-rest-maturity-model, api-conditional-requests
+
+## Success Criteria
+
+- Every endpoint uses the HTTP method whose safety and idempotency properties match the operation's actual behavior.
+- GET and HEAD requests produce no visible state changes on any resource.
+- PUT requests replace the full resource; PATCH requests update only specified fields.
+- POST creation responses return `201 Created` with a `Location` header.
+- DELETE and PUT are safe to retry without idempotency keys; POST and PATCH endpoints either accept idempotency keys or document that retries may produce duplicates.

package/dist/agents/skills/cursor/api-http-methods/skill.yaml

@@ -0,0 +1,43 @@
+name: api-http-methods
+version: '1.0.0'
+description: GET/POST/PUT/PATCH/DELETE semantics, safety and idempotency properties, and when to use each HTTP method
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-status-codes
+  - api-idempotency-keys
+  - api-rest-maturity-model
+  - api-conditional-requests
+stack_signals:
+  - rest
+  - api
+  - http
+keywords:
+  - http-methods
+  - GET
+  - POST
+  - PUT
+  - PATCH
+  - DELETE
+  - safety
+  - idempotency
+  - HEAD
+  - OPTIONS
+metadata:
+  author: community
+  upstream: developer.mozilla.org/en-US/docs/Web/HTTP/Methods
+state:
+  persistent: false
+  files: []
+depends_on: []