@giveitsmaller/contracts 0.72.0 → 0.73.0

package/README.md

@@ -5,8 +5,8 @@
 
 | | |
 |---|---|
-| Package version | `0.72.0` |
-| Generated from spec | **`v2.203.0`** |
+| Package version | `0.73.0` |
+| Generated from spec | **`v2.208.0`** |
 
 ## Two version lines, and they are not comparable
 

package/accepted-options/accepted-options.json

@@ -1214,5 +1214,5 @@
       }
     }
   },
-  "schema_version": "2.203.0"
+  "schema_version": "2.208.0"
 }

package/accepted-options/image-output-routes.json

@@ -246,5 +246,5 @@
       "source_op": "compress"
     }
   },
-  "schema_version": "2.203.0"
+  "schema_version": "2.208.0"
 }

package/asyncapi/events.yaml

@@ -779,12 +779,12 @@ channels:
     address: gisl-{env}-{region}-ops-custom-luma
     description: |
       SQS queue for custom_luma operations (caller-uploaded luma matte
-      transition; pro-tier paid feature). Subscribed to the
+      transition; credit-metered, no tier gate). Subscribed to the
       `operations` SNS topic with filter `operation_type = custom_luma`.
       Multi-input (Path B with `role: base` + `role: transition_mask`
       per `JobInputV2.role`).
 
-      `custom_luma` is `availability: planned` + `required_tier: pro`
+      `custom_luma` is `availability: planned` (no tier gate)
       per the operation schema; the API rejects workflow-create with
       `feature_not_available` (422) until the Lambda ships, so traffic
       does not reach this queue today. Backed by the
@@ -2040,7 +2040,7 @@ operations:
       yet shipped) consumes custom_luma requests routed by
       `operation_type=custom_luma`. Multi-input (Path B with
       `role: base` + `role: transition_mask` per `JobInputV2.role`).
-      `availability: planned` + `required_tier: pro`; the API rejects
+      `availability: planned` (no tier gate); the API rejects
       workflow-create with `feature_not_available` (422) until the
       Lambda ships, so traffic does not reach this channel today.
       Per ADR-0004 + I29 (Trello EPUE5Vs1).
@@ -3336,6 +3336,10 @@ components:
     PerMimeAvailability:
       type: object
       description: |
+        **CLOSED TO NEW DECLARATIONS since 2026-09-18** ([`DquOfy7f`](https://trello.com/c/DquOfy7f)).
+        Retained for compatibility only; `scripts/check-per-mime-availability.py`
+        fails on any declaration. Use a parallel mime_group instead.
+
         Map of MIME-type → `PerValueAvailabilityEntry`. Mirrors the
         OpenAPI `PerMimeAvailability` schema so SDK generators
         consuming both specs emit a single typed binding.
@@ -5296,8 +5300,8 @@ components:
         - `custom_luma`: Apply a caller-uploaded luma matte to a base
           video for a custom luma-matte transition effect. Multi-input
           (Path B with `role: base` + `role: transition_mask` per
-          `JobInputV2.role`). `availability: planned` +
-          `required_tier: pro` per the operation schema; the API
+          `JobInputV2.role`). `availability: planned`
+          (no tier gate) per the operation schema; the API
           rejects workflow-create with `feature_not_available` (422)
           until the Lambda ships, so traffic does not reach SNS today.
           When Lambda support lands, routes via

package/availability/availability.json

@@ -1,6 +1,6 @@
 {
   "capabilities_profile": "baseline",
-  "capabilities_version": 187,
+  "capabilities_version": 190,
   "endpoints": {
     "DELETE /api/auth/account": {
       "auth": "required",
@@ -526,8 +526,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -690,8 +689,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -2125,8 +2123,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -2660,8 +2657,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -2678,7 +2674,7 @@
     "custom_luma": {
       "availability": "planned",
       "default": false,
-      "description": "Apply a caller-uploaded luma matte (transition-mask) over a base\nvideo to produce a custom luma-matte transition effect. Inspired\nby Cloudinary's deprecated luma-matte custom transitions and\nintended as a paid-tier (`pro`+) creative feature.\n\n**NOT** related to the `xfade=custom` expression-mode transition\nparameter. The `merge.transition.custom` value is tagged `planned`\nas an advisory that points callers at this dedicated operation for\ncaller-uploaded luma-matte transitions.\n\nMulti-input: exactly one input with `role: base` (the source\nvideo being transitioned) + exactly one input with\n`role: transition_mask` (the luma matte \u2014 a video whose pixel\nluminance drives the transition reveal \u2014 bright = revealed,\ndark = held). Each input is imported\nexternally, referenced from a vault connection, or an upstream\n`job_output` (uploads are NOT referenced directly inside inputs[]).\nAn uploaded base or mask enters via a `passthrough` source job\nreferenced by `{ type: job_output, from: <id> }` (per ticket\n4som89Uh).\n\n`planned` \u2014 not yet supported.\n",
+      "description": "Apply a caller-uploaded luma matte (transition-mask) over a base\nvideo to produce a custom luma-matte transition effect. Inspired\nby Cloudinary's deprecated luma-matte custom transitions and\nintended as a creative feature, metered by credits like every\nother operation (no tier gate \u2014 decision 26, 2026-09-23).\n\n**NOT** related to the `xfade=custom` expression-mode transition\nparameter. The `merge.transition.custom` value is tagged `planned`\nas an advisory that points callers at this dedicated operation for\ncaller-uploaded luma-matte transitions.\n\nMulti-input: exactly one input with `role: base` (the source\nvideo being transitioned) + exactly one input with\n`role: transition_mask` (the luma matte \u2014 a video whose pixel\nluminance drives the transition reveal \u2014 bright = revealed,\ndark = held). Each input is imported\nexternally, referenced from a vault connection, or an upstream\n`job_output` (uploads are NOT referenced directly inside inputs[]).\nAn uploaded base or mask enters via a `passthrough` source job\nreferenced by `{ type: job_output, from: <id> }` (per ticket\n4som89Uh).\n\n`planned` \u2014 not yet supported.\n",
       "input_model": "multi",
       "max_inputs": 2,
       "mime_groups": {
@@ -2738,8 +2734,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -2747,8 +2742,7 @@
                 "max_input_duration": "PT5M",
                 "max_input_size_bytes": 524288000,
                 "max_output_size_bytes": 524288000
-              },
-              "required_tier": "pro"
+              }
             }
           }
         }
@@ -2764,7 +2758,6 @@
           "min": 1
         }
       },
-      "required_tier": "pro",
       "sole_op": true
     },
     "image_watermark": {
@@ -3788,8 +3781,7 @@
                 "max": {
                   "max_total_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form_concat": {
               "availability": "stable",
@@ -3912,6 +3904,7 @@
       "mime_groups": {
         "audio": {
           "availability": "beta",
+          "input_size_bound": "processing_time",
           "mimes": [
             "audio/mpeg",
             "audio/aac",
@@ -3973,7 +3966,7 @@
             },
             "precision": {
               "default": "fast",
-              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n",
+              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n\n\ud83d\udd34 **THE TWO VALUES HAVE DIFFERENT DURATION LIMITS, AND ONLY\nONE OF THEM REFUSES.** This is stated here, on the option a\ncaller chooses, because the group declares\n`input_size_bound: processing_time` and no\n`max_input_duration` \u2014 there is no per-value constraint\nprimitive to carry it.\n\n\u26d4 **NEITHER VALUE GIVES A PRE-FLIGHT SIGNAL. BOTH FAIL AFTER\nTHE JOB IS ACCEPTED AND BILLED.** No duration ceiling is\ndeclared on this group, so the API cannot enforce one at\ncreate; the worker's own check reads a probe result, which\nmeans the input has already been uploaded, accepted and\ndownloaded.\n\n- **`exact`: refused when its computed time budget does not\n  fit** \u2014 but WORKER-SIDE, after download and probe. The job\n  returns a terminal `OperationResult` with `error_code:\n  invalid_options`. \u26a0\ufe0f It is NOT an HTTP 422 and it is not a\n  create-time rejection: a worker cannot emit a status code.\n  The boundary does not move with `count` \u2014 once the cap\n  binds, the per-output term stops mattering.\n- **`fast` (the default): no boundary and no refusal at\n  all.** Past the point where its deadline saturates, the time\n  budget stops growing while the work does, so the job fails\n  as a **TIMEOUT** rather than with any reason a caller can\n  act on.\n\n\ud83d\udd34 **TWO LIMITS EXIST AND THE SMALLER ONE BINDS.** The worker\ncarries an internal time budget and the Lambda function\ncarries a platform timeout; **the effective boundary is the\nLOWER of the two**, and the internal budget sits ABOVE the\nplatform timeout.\n\n\u21d2 **`exact`'s refusal threshold is calibrated to a limit that\nis not the one that ends the job.** Its check does fire, and\nfires early \u2014 it reads the probe result before any re-encode\nstarts, so a long-but-small input is refused within seconds.\nBut there is a band of inputs it judges FINE which the\nplatform then hard-kills mid-encode, with no named cause. **So\n`exact` refusing is a reliable signal; `exact` NOT refusing is\nnot a promise the job will finish.**\n\n\u26d4 **NO SECONDS FIGURE IS GIVEN HERE, DELIBERATELY.** v2.205.0\npublished figures keyed to the crate constant \u2014 the larger\nlimit, the one that does not bind. The effective number lands\nonly when that derivation settles AND a job is measured near\nit. **A published number a caller pre-validates against is\nworse wrong than absent**; the shape above is what a caller can\nactually act on today, which is: do not rely on either value\nfailing gracefully.\n\n\u21d2 `exact` at least names a cause when it is reached; `fast`\nnever does. **Both are the accept-then-bill-then-fail shape**,\nwhich is the very thing this group's `input_size_bound`\ndeclaration exists to stop happening silently on the BYTE\naxis. On the DURATION axis it is stated here and not yet\nfixed.\n\n\u26a0\ufe0f Read from `compression_lambdas` `crates/split`. **NOT\nmeasured** \u2014 their audio fixtures reach 145 s, a small\nfraction of any candidate cap, so this describes what the code\nwill do rather than observed behaviour at the boundary.\n",
               "type": "enum",
               "values": [
                 "fast",
@@ -4149,8 +4142,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "beta",
@@ -4812,8 +4804,7 @@
                 "max": {
                   "max_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -4963,8 +4954,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -4993,7 +4983,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n",
+              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. THE REJECTION AS WRITTEN CANNOT SURVIVE A\nNON-ZERO DEFAULT; IGNORING IS THE REPLACEMENT THAT WAS CHOSEN.**\nThe sibling operations still reject a non-zero\nmargin at `anchor: center` as `invalid_options` (422), and\nthat rule is sound THERE because their margin default is\n`0px`: a client that materialises the default sends `0px`,\nwhich is not non-zero, so only a caller who actually asked\nfor an offset is ever refused.\n\n\u26d4 **Here the default is `2%`, and that makes the rejection\nrule unusable as written.** Schema-driven clients fill contract\ndefaults BEFORE sending, so a request with `anchor: center`\narrives carrying `margin_x: \"2%\"` whether the caller chose it\nor never mentioned margins at all. **After default\nmaterialisation an explicit value and a defaulted one are\nINDISTINGUISHABLE on the wire**, so a rejection cannot\nseparate the mistake it exists to catch from the overwhelming\nmajority of requests that simply accepted the default. It\nwould 422 almost every centred watermark.\n\n\u26a0\ufe0f **Rejection is not the only alternative, and this text does\nnot claim it was forced.** A reject-if-it-differs-from-the-\ndefault rule would survive materialisation exactly as the zero\nrule does for the siblings. **Ignoring is the behaviour CHOSEN**\nunder hub decision 465, because margins are meaningless when the\nlabel is centred and a no-op is kinder than a 422 on a request\nthat renders correctly. The cost is stated: a caller who\ndeliberately passes a margin with `anchor: center` gets silence\nrather than a correction.\n\n\u26a0\ufe0f **DO NOT \"align\" `text_watermark` or `image_watermark` to\nthis on the strength of the operation NAME.** Their rejection\nstill works because their default is still `0px`. Changing one\nof THOSE defaults to non-zero is what would force the same move\nthere \u2014 the trigger is a non-zero default, never the operation\nname. (`video_watermark` moved with this operation because its\ndefault moved too, under the same decision.)\n",
               "type": "enum",
               "values": [
                 "top_left",
@@ -5029,14 +5019,14 @@
               "type": "float"
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Non-zero `margin_x` combined with `anchor: center`\nis rejected by the API at workflow-create time as\n`invalid_options` (HTTP 422).\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly** \u2014 the default is a default, not a\nfloor.\n\n**`anchor: center`: margins are IGNORED** (watermark_mode:\nsingle only). They are meaningless when the label is centred,\nand this is deliberately a silent no-op rather than a\nrejection. See the `anchor` description for why rejection is\nnot available here.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Same rejection rule as `margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: ignored**,\nsame as `margin_x`.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
@@ -5095,8 +5085,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -5132,7 +5121,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n",
+              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. The rejection as written cannot survive a\nnon-zero default; ignoring is the replacement that was CHOSEN.\nThe trigger is the DEFAULT, not this operation.** Schema-driven\nclients materialise contract\ndefaults BEFORE sending, so with a non-zero default a centred\nrequest arrives carrying `margin_x: \"2%\"` whether the caller\nchose it or never mentioned margins. **After materialisation\nan explicit value and a defaulted one are indistinguishable on\nthe wire**, so the old `invalid_options` (422) rule would\nrefuse nearly every centred watermark.\n\n\u26a0\ufe0f Rejection is not the only alternative \u2014 a\nreject-if-it-differs-from-the-default rule would also survive\nmaterialisation. **Ignoring is the behaviour CHOSEN** under hub\ndecision 465, because margins are meaningless when the label is\ncentred. The cost is stated: a caller who deliberately passes a\nmargin with `anchor: center` gets silence, not a correction.\n\n\u26a0\ufe0f **The trigger is a NON-ZERO DEFAULT, never an operation\nname.** `image_watermark` and `text_watermark` keep their 422\nbecause their defaults are still `0px`, where a materialised\ndefault is not non-zero and only a deliberate offset is\nrefused.\n",
               "type": "enum",
               "values": [
                 "top_left",
@@ -5147,14 +5136,14 @@
               ]
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**`anchor: center` exception.** When the anchor is `center`\nthe centre is the centre \u2014 there is no anchor-relative\ndirection. Non-zero `margin_x` combined with\n`anchor: center` is rejected by the API at workflow-create\ntime as `invalid_options` (HTTP 422). Same rule as the\nother watermark operations.\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly.**\n\n**`anchor: center`: margins are IGNORED.** The centre is the\ncentre \u2014 there is no anchor-relative direction \u2014 so this is a\nsilent no-op rather than a rejection. See the `anchor`\ndescription for why a rejection is not usable with a non-zero\ndefault.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**`anchor: center` exception.** Same rejection rule as\n`margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: margins\nare IGNORED**, same as `margin_x`.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
@@ -5188,8 +5177,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -5216,7 +5204,7 @@
       "sole_op": true
     }
   },
-  "schema_version": "2.203.0",
+  "schema_version": "2.208.0",
   "source_commit": null,
   "user_tier": null,
   "workflow_features": {

package/code-builder/code-builder-metadata.json

@@ -479,8 +479,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -699,8 +698,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -3026,8 +3024,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -3772,8 +3769,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -3879,8 +3875,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -3888,8 +3883,7 @@
                 "max_input_duration": "PT5M",
                 "max_input_size_bytes": 524288000,
                 "max_output_size_bytes": 524288000
-              },
-              "required_tier": "pro"
+              }
             }
           }
         }
@@ -5239,8 +5233,7 @@
                 "max": {
                   "max_total_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form_concat": {
               "availability": "stable",
@@ -5393,6 +5386,7 @@
       "media_groups": {
         "audio": {
           "availability": "beta",
+          "input_size_bound": "processing_time",
           "media_group": "audio",
           "mimes": [
             "audio/mpeg",
@@ -5474,7 +5468,7 @@
             },
             "precision": {
               "default": "fast",
-              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n",
+              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n\n\ud83d\udd34 **THE TWO VALUES HAVE DIFFERENT DURATION LIMITS, AND ONLY\nONE OF THEM REFUSES.** This is stated here, on the option a\ncaller chooses, because the group declares\n`input_size_bound: processing_time` and no\n`max_input_duration` \u2014 there is no per-value constraint\nprimitive to carry it.\n\n\u26d4 **NEITHER VALUE GIVES A PRE-FLIGHT SIGNAL. BOTH FAIL AFTER\nTHE JOB IS ACCEPTED AND BILLED.** No duration ceiling is\ndeclared on this group, so the API cannot enforce one at\ncreate; the worker's own check reads a probe result, which\nmeans the input has already been uploaded, accepted and\ndownloaded.\n\n- **`exact`: refused when its computed time budget does not\n  fit** \u2014 but WORKER-SIDE, after download and probe. The job\n  returns a terminal `OperationResult` with `error_code:\n  invalid_options`. \u26a0\ufe0f It is NOT an HTTP 422 and it is not a\n  create-time rejection: a worker cannot emit a status code.\n  The boundary does not move with `count` \u2014 once the cap\n  binds, the per-output term stops mattering.\n- **`fast` (the default): no boundary and no refusal at\n  all.** Past the point where its deadline saturates, the time\n  budget stops growing while the work does, so the job fails\n  as a **TIMEOUT** rather than with any reason a caller can\n  act on.\n\n\ud83d\udd34 **TWO LIMITS EXIST AND THE SMALLER ONE BINDS.** The worker\ncarries an internal time budget and the Lambda function\ncarries a platform timeout; **the effective boundary is the\nLOWER of the two**, and the internal budget sits ABOVE the\nplatform timeout.\n\n\u21d2 **`exact`'s refusal threshold is calibrated to a limit that\nis not the one that ends the job.** Its check does fire, and\nfires early \u2014 it reads the probe result before any re-encode\nstarts, so a long-but-small input is refused within seconds.\nBut there is a band of inputs it judges FINE which the\nplatform then hard-kills mid-encode, with no named cause. **So\n`exact` refusing is a reliable signal; `exact` NOT refusing is\nnot a promise the job will finish.**\n\n\u26d4 **NO SECONDS FIGURE IS GIVEN HERE, DELIBERATELY.** v2.205.0\npublished figures keyed to the crate constant \u2014 the larger\nlimit, the one that does not bind. The effective number lands\nonly when that derivation settles AND a job is measured near\nit. **A published number a caller pre-validates against is\nworse wrong than absent**; the shape above is what a caller can\nactually act on today, which is: do not rely on either value\nfailing gracefully.\n\n\u21d2 `exact` at least names a cause when it is reached; `fast`\nnever does. **Both are the accept-then-bill-then-fail shape**,\nwhich is the very thing this group's `input_size_bound`\ndeclaration exists to stop happening silently on the BYTE\naxis. On the DURATION axis it is stated here and not yet\nfixed.\n\n\u26a0\ufe0f Read from `compression_lambdas` `crates/split`. **NOT\nmeasured** \u2014 their audio fixtures reach 145 s, a small\nfraction of any candidate cap, so this describes what the code\nwill do rather than observed behaviour at the boundary.\n",
               "origin": "contract",
               "sdk_exposure": "expose",
               "surface_key": "precision",
@@ -5722,8 +5716,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "beta",
@@ -6724,8 +6717,7 @@
                 "max": {
                   "max_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -6952,8 +6944,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -6990,7 +6981,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n",
+              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. THE REJECTION AS WRITTEN CANNOT SURVIVE A\nNON-ZERO DEFAULT; IGNORING IS THE REPLACEMENT THAT WAS CHOSEN.**\nThe sibling operations still reject a non-zero\nmargin at `anchor: center` as `invalid_options` (422), and\nthat rule is sound THERE because their margin default is\n`0px`: a client that materialises the default sends `0px`,\nwhich is not non-zero, so only a caller who actually asked\nfor an offset is ever refused.\n\n\u26d4 **Here the default is `2%`, and that makes the rejection\nrule unusable as written.** Schema-driven clients fill contract\ndefaults BEFORE sending, so a request with `anchor: center`\narrives carrying `margin_x: \"2%\"` whether the caller chose it\nor never mentioned margins at all. **After default\nmaterialisation an explicit value and a defaulted one are\nINDISTINGUISHABLE on the wire**, so a rejection cannot\nseparate the mistake it exists to catch from the overwhelming\nmajority of requests that simply accepted the default. It\nwould 422 almost every centred watermark.\n\n\u26a0\ufe0f **Rejection is not the only alternative, and this text does\nnot claim it was forced.** A reject-if-it-differs-from-the-\ndefault rule would survive materialisation exactly as the zero\nrule does for the siblings. **Ignoring is the behaviour CHOSEN**\nunder hub decision 465, because margins are meaningless when the\nlabel is centred and a no-op is kinder than a 422 on a request\nthat renders correctly. The cost is stated: a caller who\ndeliberately passes a margin with `anchor: center` gets silence\nrather than a correction.\n\n\u26a0\ufe0f **DO NOT \"align\" `text_watermark` or `image_watermark` to\nthis on the strength of the operation NAME.** Their rejection\nstill works because their default is still `0px`. Changing one\nof THOSE defaults to non-zero is what would force the same move\nthere \u2014 the trigger is a non-zero default, never the operation\nname. (`video_watermark` moved with this operation because its\ndefault moved too, under the same decision.)\n",
               "origin": "contract",
               "sdk_exposure": "coming_soon",
               "surface_key": "anchor",
@@ -7052,8 +7043,8 @@
               "type": "float"
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Non-zero `margin_x` combined with `anchor: center`\nis rejected by the API at workflow-create time as\n`invalid_options` (HTTP 422).\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly** \u2014 the default is a default, not a\nfloor.\n\n**`anchor: center`: margins are IGNORED** (watermark_mode:\nsingle only). They are meaningless when the label is centred,\nand this is deliberately a silent no-op rather than a\nrejection. See the `anchor` description for why rejection is\nnot available here.\n",
               "origin": "contract",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "sdk_exposure": "coming_soon",
@@ -7061,8 +7052,8 @@
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Same rejection rule as `margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: ignored**,\nsame as `margin_x`.\n",
               "origin": "contract",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "sdk_exposure": "coming_soon",
@@ -7144,8 +7135,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -7194,7 +7184,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n",
+              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. The rejection as written cannot survive a\nnon-zero default; ignoring is the replacement that was CHOSEN.\nThe trigger is the DEFAULT, not this operation.** Schema-driven\nclients materialise contract\ndefaults BEFORE sending, so with a non-zero default a centred\nrequest arrives carrying `margin_x: \"2%\"` whether the caller\nchose it or never mentioned margins. **After materialisation\nan explicit value and a defaulted one are indistinguishable on\nthe wire**, so the old `invalid_options` (422) rule would\nrefuse nearly every centred watermark.\n\n\u26a0\ufe0f Rejection is not the only alternative \u2014 a\nreject-if-it-differs-from-the-default rule would also survive\nmaterialisation. **Ignoring is the behaviour CHOSEN** under hub\ndecision 465, because margins are meaningless when the label is\ncentred. The cost is stated: a caller who deliberately passes a\nmargin with `anchor: center` gets silence, not a correction.\n\n\u26a0\ufe0f **The trigger is a NON-ZERO DEFAULT, never an operation\nname.** `image_watermark` and `text_watermark` keep their 422\nbecause their defaults are still `0px`, where a materialised\ndefault is not non-zero and only a deliberate offset is\nrefused.\n",
               "origin": "contract",
               "sdk_exposure": "coming_soon",
               "surface_key": "anchor",
@@ -7223,8 +7213,8 @@
               ]
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**`anchor: center` exception.** When the anchor is `center`\nthe centre is the centre \u2014 there is no anchor-relative\ndirection. Non-zero `margin_x` combined with\n`anchor: center` is rejected by the API at workflow-create\ntime as `invalid_options` (HTTP 422). Same rule as the\nother watermark operations.\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly.**\n\n**`anchor: center`: margins are IGNORED.** The centre is the\ncentre \u2014 there is no anchor-relative direction \u2014 so this is a\nsilent no-op rather than a rejection. See the `anchor`\ndescription for why a rejection is not usable with a non-zero\ndefault.\n",
               "origin": "contract",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "sdk_exposure": "coming_soon",
@@ -7232,8 +7222,8 @@
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**`anchor: center` exception.** Same rejection rule as\n`margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: margins\nare IGNORED**, same as `margin_x`.\n",
               "origin": "contract",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "sdk_exposure": "coming_soon",
@@ -7276,8 +7266,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -7297,7 +7286,7 @@
     }
   },
   "preset_config_hash": "sha256:354814f7906f85be6a6ca5ede6c0722c83cdc058fd658a9bb2b0996520466c6d",
-  "schema_version": "2.203.0",
+  "schema_version": "2.208.0",
   "sdk_spec_version": "2.3.0",
-  "source_hash": "sha256:7123426cdc40dc649a48968e2589d90eb7ff7da5a3fe32f55bc19a4d6d9f2eaa"
+  "source_hash": "sha256:5b27659d918e263faa1fd74f3ff638acae77f7b666d27aca85d66f803035508f"
 }

package/dist/openapi/models/AccountLimitEntry.d.ts

@@ -2,7 +2,7 @@
  * GISL Compression API
  * REST API for the GISL (Give It Smaller) file compression and processing service.  **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output  **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body.  **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings.  The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17).  **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).**  Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English.  - **Currently committed locales:** `en-GB` only (per ticket   [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier   shape (`Accept-Language` + `Content-Language` + `Vary` headers +   `locale` envelope field + `message_key` + `message_params`) is   stable and exercised; the **catalog** of translated `message`   strings is en-GB-only at runtime today. Additional locales (e.g.   `pt-PT`) will be advertised by name when their catalogs ship —   the request/response carrier shape does NOT change when a new   locale lands. Treat unrequested locales as \"machine-code +   `message_key` path is committed; localised `message` prose is   not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value   negotiation supported). The server selects the best-match locale   from its supported list; falls back to `en-GB` when no match —   which, until additional catalogs land, is every non-`en-GB`   `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised   response; `Vary: Accept-Language` on every response (CDN/cache   correctness — different `Accept-Language` requests produce   different responses). `Vary` is emitted unconditionally so the   header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for   `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed   error branches; surface `message_key` to client-side i18n   catalogs (SDK companion work tracked at X19, cross-repo);   display `message` for end-user UI; **never parse `message` for   control flow** — it changes per locale.  Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention.  **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
  *
- * The version of the OpenAPI document: 2.203.0
+ * The version of the OpenAPI document: 2.208.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/openapi/models/AccountLimitEntry.js

@@ -4,7 +4,7 @@
  * GISL Compression API
  * REST API for the GISL (Give It Smaller) file compression and processing service.  **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output  **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body.  **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings.  The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17).  **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).**  Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English.  - **Currently committed locales:** `en-GB` only (per ticket   [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier   shape (`Accept-Language` + `Content-Language` + `Vary` headers +   `locale` envelope field + `message_key` + `message_params`) is   stable and exercised; the **catalog** of translated `message`   strings is en-GB-only at runtime today. Additional locales (e.g.   `pt-PT`) will be advertised by name when their catalogs ship —   the request/response carrier shape does NOT change when a new   locale lands. Treat unrequested locales as \"machine-code +   `message_key` path is committed; localised `message` prose is   not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value   negotiation supported). The server selects the best-match locale   from its supported list; falls back to `en-GB` when no match —   which, until additional catalogs land, is every non-`en-GB`   `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised   response; `Vary: Accept-Language` on every response (CDN/cache   correctness — different `Accept-Language` requests produce   different responses). `Vary` is emitted unconditionally so the   header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for   `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed   error branches; surface `message_key` to client-side i18n   catalogs (SDK companion work tracked at X19, cross-repo);   display `message` for end-user UI; **never parse `message` for   control flow** — it changes per locale.  Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention.  **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
  *
- * The version of the OpenAPI document: 2.203.0
+ * The version of the OpenAPI document: 2.208.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/openapi/models/AccountLimits.d.ts

@@ -2,7 +2,7 @@
  * GISL Compression API
  * REST API for the GISL (Give It Smaller) file compression and processing service.  **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output  **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body.  **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings.  The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17).  **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).**  Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English.  - **Currently committed locales:** `en-GB` only (per ticket   [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier   shape (`Accept-Language` + `Content-Language` + `Vary` headers +   `locale` envelope field + `message_key` + `message_params`) is   stable and exercised; the **catalog** of translated `message`   strings is en-GB-only at runtime today. Additional locales (e.g.   `pt-PT`) will be advertised by name when their catalogs ship —   the request/response carrier shape does NOT change when a new   locale lands. Treat unrequested locales as \"machine-code +   `message_key` path is committed; localised `message` prose is   not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value   negotiation supported). The server selects the best-match locale   from its supported list; falls back to `en-GB` when no match —   which, until additional catalogs land, is every non-`en-GB`   `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised   response; `Vary: Accept-Language` on every response (CDN/cache   correctness — different `Accept-Language` requests produce   different responses). `Vary` is emitted unconditionally so the   header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for   `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed   error branches; surface `message_key` to client-side i18n   catalogs (SDK companion work tracked at X19, cross-repo);   display `message` for end-user UI; **never parse `message` for   control flow** — it changes per locale.  Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention.  **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
  *
- * The version of the OpenAPI document: 2.203.0
+ * The version of the OpenAPI document: 2.208.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/openapi/models/AccountLimits.js

@@ -4,7 +4,7 @@
  * GISL Compression API
  * REST API for the GISL (Give It Smaller) file compression and processing service.  **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output  **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body.  **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings.  The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17).  **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).**  Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English.  - **Currently committed locales:** `en-GB` only (per ticket   [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier   shape (`Accept-Language` + `Content-Language` + `Vary` headers +   `locale` envelope field + `message_key` + `message_params`) is   stable and exercised; the **catalog** of translated `message`   strings is en-GB-only at runtime today. Additional locales (e.g.   `pt-PT`) will be advertised by name when their catalogs ship —   the request/response carrier shape does NOT change when a new   locale lands. Treat unrequested locales as \"machine-code +   `message_key` path is committed; localised `message` prose is   not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value   negotiation supported). The server selects the best-match locale   from its supported list; falls back to `en-GB` when no match —   which, until additional catalogs land, is every non-`en-GB`   `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised   response; `Vary: Accept-Language` on every response (CDN/cache   correctness — different `Accept-Language` requests produce   different responses). `Vary` is emitted unconditionally so the   header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for   `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed   error branches; surface `message_key` to client-side i18n   catalogs (SDK companion work tracked at X19, cross-repo);   display `message` for end-user UI; **never parse `message` for   control flow** — it changes per locale.  Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention.  **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
  *
- * The version of the OpenAPI document: 2.203.0
+ * The version of the OpenAPI document: 2.208.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).