@giveitsmaller/contracts 0.61.0 → 0.63.0

package/operation-capabilities/operation-capabilities.json

@@ -732,5 +732,5 @@
       "isAnimated": "maybe"
     }
   },
-  "schema_version": "2.189.0"
+  "schema_version": "2.192.0"
 }

package/operations/README.md

@@ -0,0 +1,17 @@
+# TypeScript -- Operation Option Models
+
+> **Auto-generated** -- do not edit manually. Changes will be overwritten on the next generation run.
+>
+> Regenerate with: `make project/generate-tests`
+
+## Source
+
+- **Spec:** `compression_contracts/schemas/operations/*.yaml` (custom schema format)
+- **Generator:** Custom Python emitter (`scripts/generators/operation_schema/typescript.py`)
+- **Files:** 35
+
+## Contents
+
+TypeScript enums and interfaces for per-operation options (compression quality, thumbnail dimensions, conversion formats, etc.).
+
+Operation types covered: archive, audio_overlay, audio_to_video, audio_watermark, compress, convert, custom_luma, image_watermark, merge, passthrough, render_variants, split, text_watermark, thumbnail, transform, video_text_watermark, video_watermark.

package/operations/schemas/compress.yaml

@@ -1268,7 +1268,25 @@ operation:
         - application/vnd.openxmlformats-officedocument.wordprocessingml.document
         - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
         - application/vnd.openxmlformats-officedocument.presentationml.presentation
-      max_input_size_bytes: 104857600   # 100 MiB compress input ceiling (uKsFzORi; zip-based worker MAX_INPUT_SIZE)
+      # 200 MiB. RAISED from 100 MiB (Y0tkvebF, lambdas-measured 2026-08-12).
+      # The old cap was real in MECHANISM and calibrated against the WRONG
+      # NUMBER: the ZIP strategy needs Read+Seek so the whole document is in
+      # memory (peak ~= 2x input + largest entry), and the worker comment
+      # justified 100 MiB as fitting "a Lambda with 512 MB+ memory" — but
+      # gisl-{stg,prod}-euw1-compression-document is 3008 MiB, six times that.
+      # At 200 MiB input, peak ~= 450 MiB = 15% of the function.
+      #
+      # WHY IT HAD TO MOVE: hub decision 22 raises the free UPLOAD cap to
+      # ~150 MB, which sits ABOVE this PROCESSING cap — so a free user would
+      # upload a 140 MB DOCX successfully and have the OPERATION reject it.
+      # Under the old 10 MiB upload cap that window could not exist; raising
+      # the upload cap created it.
+      #
+      # ⚠️ The ZIP-bomb guards are a DIFFERENT axis and did NOT move:
+      # MAX_IMAGE_ENTRY_SIZE 50 MB, MAX_ZIP_ENTRIES 10,000,
+      # MAX_CUMULATIVE_IMAGE_BYTES 500 MB bound what a document expands INTO;
+      # this bounds what we ACCEPT.
+      max_input_size_bytes: 209715200
       # See the document_pdf honesty note: the worker reads ONLY `quality` today;
       # the per-format options are `planned` (advertised-ahead, FE-hidden).
       options:
@@ -1301,7 +1319,25 @@ operation:
         - application/vnd.oasis.opendocument.text
         - application/vnd.oasis.opendocument.spreadsheet
         - application/vnd.oasis.opendocument.presentation
-      max_input_size_bytes: 104857600   # 100 MiB compress input ceiling (uKsFzORi; zip-based worker MAX_INPUT_SIZE)
+      # 200 MiB. RAISED from 100 MiB (Y0tkvebF, lambdas-measured 2026-08-12).
+      # The old cap was real in MECHANISM and calibrated against the WRONG
+      # NUMBER: the ZIP strategy needs Read+Seek so the whole document is in
+      # memory (peak ~= 2x input + largest entry), and the worker comment
+      # justified 100 MiB as fitting "a Lambda with 512 MB+ memory" — but
+      # gisl-{stg,prod}-euw1-compression-document is 3008 MiB, six times that.
+      # At 200 MiB input, peak ~= 450 MiB = 15% of the function.
+      #
+      # WHY IT HAD TO MOVE: hub decision 22 raises the free UPLOAD cap to
+      # ~150 MB, which sits ABOVE this PROCESSING cap — so a free user would
+      # upload a 140 MB DOCX successfully and have the OPERATION reject it.
+      # Under the old 10 MiB upload cap that window could not exist; raising
+      # the upload cap created it.
+      #
+      # ⚠️ The ZIP-bomb guards are a DIFFERENT axis and did NOT move:
+      # MAX_IMAGE_ENTRY_SIZE 50 MB, MAX_ZIP_ENTRIES 10,000,
+      # MAX_CUMULATIVE_IMAGE_BYTES 500 MB bound what a document expands INTO;
+      # this bounds what we ACCEPT.
+      max_input_size_bytes: 209715200
       # See the document_pdf honesty note: worker reads ONLY `quality`; the rest `planned`.
       options:
         quality:
@@ -1327,7 +1363,25 @@ operation:
     document_epub:
       mimes:
         - application/epub+zip
-      max_input_size_bytes: 104857600   # 100 MiB compress input ceiling (uKsFzORi; zip-based worker MAX_INPUT_SIZE)
+      # 200 MiB. RAISED from 100 MiB (Y0tkvebF, lambdas-measured 2026-08-12).
+      # The old cap was real in MECHANISM and calibrated against the WRONG
+      # NUMBER: the ZIP strategy needs Read+Seek so the whole document is in
+      # memory (peak ~= 2x input + largest entry), and the worker comment
+      # justified 100 MiB as fitting "a Lambda with 512 MB+ memory" — but
+      # gisl-{stg,prod}-euw1-compression-document is 3008 MiB, six times that.
+      # At 200 MiB input, peak ~= 450 MiB = 15% of the function.
+      #
+      # WHY IT HAD TO MOVE: hub decision 22 raises the free UPLOAD cap to
+      # ~150 MB, which sits ABOVE this PROCESSING cap — so a free user would
+      # upload a 140 MB DOCX successfully and have the OPERATION reject it.
+      # Under the old 10 MiB upload cap that window could not exist; raising
+      # the upload cap created it.
+      #
+      # ⚠️ The ZIP-bomb guards are a DIFFERENT axis and did NOT move:
+      # MAX_IMAGE_ENTRY_SIZE 50 MB, MAX_ZIP_ENTRIES 10,000,
+      # MAX_CUMULATIVE_IMAGE_BYTES 500 MB bound what a document expands INTO;
+      # this bounds what we ACCEPT.
+      max_input_size_bytes: 209715200
       # See the document_pdf honesty note: worker reads ONLY `quality`; the rest `planned`.
       options:
         quality:

package/operations/schemas/render_variants.yaml

@@ -20,9 +20,34 @@ operation:
   # Both halves were measured FALSE on 2026-07-28: the Lambda is deployed
   # (`gisl-stg-euw1-operation-render-variants`, image git-fe33902) and its event
   # source mapping has been `Enabled` on the queue since 2026-06-09. What is
-  # true is that it has never run — zero log streams, against a positive control
-  # showing non-zero for merge / compression-image / video-text-watermark in the
-  # same query. DEPLOYED and WIRED are not PROVEN, so this stays `planned`.
+  # true is that it has never run: lambdas measured CloudWatch `Invocations` for
+  # `gisl-stg-euw1-operation-render-variants` over a SIX-MONTH window on
+  # 2026-08-11 and got an EMPTY datapoint set — not a small number, zero, ever.
+  # DEPLOYED and WIRED are not PROVEN, so this stays `planned`.
+  #
+  # PROBE NOTE: that measurement supersedes the earlier "zero log streams"
+  # evidence this comment used to cite. `describe-log-streams` is NOT a valid
+  # activity probe and the fleet has been burned treating it as one; CloudWatch
+  # `Invocations` over a long window IS. Cite the metric, not the log group.
+  #
+  # AND THE UPGRADE DIRECTION IS GATED TOO. Standing policies 3 and 4 block a
+  # DOWNGRADE on absent evidence; they say nothing about an UPGRADE, and
+  # never-exercised is not a licence to flip TO `stable` either. This is the
+  # MIRROR IMAGE of the SVG case, not the same case: in both directions the
+  # honest answer to "we have never run it" is go and get the evidence. Flipping
+  # this to `stable` during a launch availability sweep would advertise to
+  # customers a worker that has never once executed. Hub ruling 2026-08-11; also
+  # on the launch checklist, because hub decision 12's "flips are safe while prod
+  # serves zero customers" protection EXPIRES WITH THE LAUNCH DATE — which is
+  # precisely when a launch sweep would touch this line. Deliberately not naming
+  # the date here: it moved THREE TIMES IN ONE DAY on 2026-08-11 and a date baked
+  # into prose rots into a false claim. Read it off the launch checklist.
+  #
+  # Deliberately citing no hub decision NUMBER either. The decision that moved
+  # the date was itself superseded within hours, and on 2026-08-12 the hub found
+  # five records reading as live that had been superseded — the supersession was
+  # written in the prose and never in the field. A record id is as perishable as
+  # the date it carries; cite the CHECKLIST, which is maintained.
   #
   # Deliberately restated as the GATE being waited on rather than a snapshot of
   # another repo's infrastructure: a gate cannot rot, a restated snapshot does —

package/package.json

@@ -1,7 +1,8 @@
 {
   "name": "@giveitsmaller/contracts",
-  "version": "0.61.0",
-  "description": "Generated contract types for GISL (Give It Smaller)",
+  "version": "0.63.0",
+  "description": "Generated contract types for GISL (Give It Smaller). Generated from compression_contracts spec v2.192.0.",
+  "gislContractsSpec": "v2.192.0",
   "license": "Apache-2.0",
   "type": "module",
   "main": "./dist/index.js",
@@ -49,6 +50,7 @@
     "./operations/schemas/video_watermark.yaml": "./operations/schemas/video_watermark.yaml"
   },
   "files": [
+    "README.md",
     "dist/",
     "openapi/api.yaml",
     "asyncapi/events.yaml",