zuplo 7.8.20 → 7.8.22

package/docs/ai-gateway/usage-limits.mdx

@@ -114,11 +114,18 @@ are enforced, but no meter on that tab tracks them.
 
 :::note{title="Budget rule periods follow the UTC calendar"}
 
-Hourly periods reset at the top of each hour, daily at 00:00 UTC, weekly on
-Monday at 00:00 UTC, and monthly on the first of the month. A rule added
-mid-period gets the full allowance for the rest of that period—the limit isn't
-prorated—and resets at the next boundary. Changing a limit mid-period doesn't
-reset the period's usage. Custom anchors aren't configurable.
+Each limit counts all applicable usage since the start of its current period:
+the top of the hour for hourly limits, 00:00 UTC for daily, Monday at 00:00 UTC
+for weekly, and 00:00 UTC on the first of the month for monthly. Usage resets at
+the next boundary. Custom anchors aren't configurable.
+
+A limit added mid-period counts usage from the start of that period, not from
+when you add it. For example, an app that has spent $150 since the first of the
+month and gets a $100 monthly **Block** limit on the 20th has already exhausted
+that limit, so its requests follow
+[what happens when a limit is exceeded](#when-a-limit-is-exceeded) until the
+next month begins. Changing a limit's amount, or removing a limit and adding it
+again, doesn't reset the period's usage.
 
 :::
 
@@ -167,10 +174,12 @@ hard cap.
 
 :::caution
 
-Changing an expression starts a new budget. The old rule's usage stays with the
-old expression, so every value's accounting restarts from zero. Expressions are
-also case-sensitive: `get("X-User")` and `get("x-user")` read the same header
-but budget separately.
+Changing an expression starts a new budget. Usage recorded under the old
+expression doesn't carry over, and the new expression can't count requests it
+never evaluated, so each value's budget usually starts from zero. If you switch
+back to an expression used earlier in the current period, the usage recorded for
+it during that period still counts. Expressions are also case-sensitive:
+`get("X-User")` and `get("x-user")` read the same header but budget separately.
 
 :::
 

package/docs/cli/delete.mdx

@@ -5,7 +5,7 @@ sidebar_label: delete
 
 <CliCommand
   command="delete"
-  description="Deletes the Zuplo API by URL"
+  description="Deletes a deployed Zuplo environment by URL or branch name"
   options={[
   {
     "name": "url",
@@ -18,10 +18,10 @@ sidebar_label: delete
   {
     "name": "branch",
     "type": "string",
-    "description": "The branch name to delete deployments for",
+    "description": "The branch name of the environment to delete (the value passed to `zuplo deploy --branch`)",
     "required": false,
     "deprecated": false,
-    "hidden": true
+    "hidden": false
   },
   {
     "name": "project",
@@ -61,12 +61,16 @@ sidebar_label: delete
     "$0 delete --url https://my-api-dev-123abc.zuplo.app",
     "Delete a deployed environment by its URL"
   ],
+  [
+    "$0 delete --branch my-feature",
+    "Delete the environment deployed from the my-feature branch"
+  ],
   [
     "$0 delete --url https://my-api-dev-123abc.zuplo.app --wait",
     "Delete an environment and wait until the deletion is complete"
   ]
 ]}
-  usage="$0 delete --url <url> [options]"
+  usage="$0 delete (--url <url> | --branch <branch>) [options]"
 >
 
 </CliCommand>

package/docs/cli/deploy.mdx

@@ -33,10 +33,18 @@ sidebar_label: deploy
     "hidden": true,
     "normalize": true
   },
+  {
+    "name": "branch",
+    "type": "string",
+    "description": "The branch name to deploy the environment as, instead of the current git branch. Overrides --environment",
+    "required": false,
+    "deprecated": false,
+    "hidden": false
+  },
   {
     "name": "environment",
     "type": "string",
-    "description": "The value to use for environment name, instead of the current branch name",
+    "description": "The value to use for environment name, instead of the current branch name (deprecated: use --branch)",
     "required": false,
     "deprecated": false,
     "hidden": false
@@ -90,12 +98,12 @@ sidebar_label: deploy
     "Deploy the current Git branch using the branch name as the environment name"
   ],
   [
-    "$0 deploy --environment my-env",
-    "Override the environment name instead of using the Git branch name"
+    "$0 deploy --branch my-feature",
+    "Deploy as the my-feature branch, e.g. from a CI job; delete it later with `zuplo delete --branch my-feature`"
   ],
   [
-    "$0 deploy --account my-account --project my-project --environment my-env",
-    "Explicitly specify the account, project, and environment"
+    "$0 deploy --account my-account --project my-project --branch my-feature",
+    "Explicitly specify the account, project, and branch"
   ]
 ]}
   usage="$0 deploy [options]"

package/docs/policies/_index.md

@@ -4,7 +4,7 @@
 | --- | --- | --- | --- |
 | set-query-params-inbound | Add or Set Query Parameters | Adds or sets query parameters on the incoming request. | api-gateway |
 | set-headers-inbound | Add or Set Request Headers | Adds or sets headers on the incoming request. | api-gateway |
-| ai-gateway-auth-v2-inbound | AI Gateway Authentication | Authenticates requests to an AI Gateway endpoint with application API keys.  Add this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header. Enable `credentialPassthrough`, with the application key in a separate header, to forward the caller's `Authorization` header to the primary provider as its credential.  When the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires the stored configuration ID to match the URL (adding `config_` for `/a`). It returns 403 on mismatch. | ai-gateway |
+| ai-gateway-auth-v2-inbound | AI Gateway Authentication | Authenticates requests to an AI Gateway endpoint with application API keys.  Add this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header. Enable `credentialPassthrough`, with the application key in a separate header, to forward the caller's `Authorization` header to the primary provider as its credential.  When the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires the stored configuration ID to match the URL (adding `config_` for `/a`). It returns 403 on mismatch.  On a User App route (`/u/{app_id}`), only a personal API key issued for that User App authenticates. `request.user.sub` is then the key owner's user ID. An application API key on a User App route, or a personal API key on any other route, returns 403. Validation results are cached for `cacheTtlSeconds`, so a revoked key stops working within that window. | ai-gateway |
 | ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already), runs the inbound policy chain from that configuration, and enforces limits inherited from parent teams or the gateway root.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
 | ai-gateway-configuration-loader-v2-inbound | AI Gateway Configuration Loader | Loads the AI Gateway app configuration for the request into the request-scoped channel and does nothing else.  Place this policy on AI Gateway routes before `ai-gateway-configuration-executor-v2-inbound` when you want configuration loading separated from chain execution. When `ai-gateway-auth-v2-inbound` already populated the channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter.  If this policy is omitted, the configuration executor still loads configuration itself before running the application chain. | ai-gateway |
 | ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering. It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |

package/docs/policies/ai-gateway-auth-v2-inbound/schema.json

@@ -12,7 +12,7 @@
   "requiresAI": true,
   "policyType": "ai-gateway-auth-v2",
   "products": ["ai-gateway"],
-  "description": "Authenticates requests to an AI Gateway endpoint with application API keys.\n\nAdd this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header. Enable `credentialPassthrough`, with the application key in a separate header, to forward the caller's `Authorization` header to the primary provider as its credential.\n\nWhen the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires the stored configuration ID to match the URL (adding `config_` for `/a`). It returns 403 on mismatch.",
+  "description": "Authenticates requests to an AI Gateway endpoint with application API keys.\n\nAdd this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header. Enable `credentialPassthrough`, with the application key in a separate header, to forward the caller's `Authorization` header to the primary provider as its credential.\n\nWhen the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires the stored configuration ID to match the URL (adding `config_` for `/a`). It returns 403 on mismatch.\n\nOn a User App route (`/u/{app_id}`), only a personal API key issued for that User App authenticates. `request.user.sub` is then the key owner's user ID. An application API key on a User App route, or a personal API key on any other route, returns 403. Validation results are cached for `cacheTtlSeconds`, so a revoked key stops working within that window.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.8.20",
+  "version": "7.8.22",
   "type": "module",
   "description": "The official Zuplo CLI for local development and platform management",
   "homepage": "https://zuplo.com/docs/cli/overview",
@@ -32,9 +32,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.8.20",
-    "@zuplo/core": "7.8.20",
-    "@zuplo/runtime": "7.8.20",
-    "@zuplo/test": "7.8.20"
+    "@zuplo/cli": "7.8.22",
+    "@zuplo/core": "7.8.22",
+    "@zuplo/runtime": "7.8.22",
+    "@zuplo/test": "7.8.22"
   }
 }