@jimhoyd/urlcode 0.4.0-alpha.1 → 0.4.0-alpha.2

package/docs/VERSION-ALIGNMENT.md

@@ -0,0 +1,205 @@
+# Core version alignment across repositories
+
+Which core version each downstream package supports, how it says so, and the
+order in which a core behavior change reaches downstream repositories. This
+page is a mechanism and an invariant, not a schedule: it states no release
+cadence, no LTS line and no support window. Those are not decided.
+
+It exists because "the current core" had come to mean five different things at
+once, and one of them did not resolve. The `0.4.0-alpha.2` release closes that;
+the table below is where every repository lands, and it is the register to
+change whenever a version changes anywhere.
+
+| Repository | How it names core | Value (read from its own `package.json`/`peers.json`) |
+|---|---|---|
+| `urlcode` | source version | `0.4.0-alpha.2` |
+| `urlcode-auth`, `urlcode-admin` | peer range plus a reviewed SHA | `>=0.4.0-alpha.1 <0.5.0`; `peers.json` `urlcode` = `d5e86017e93b96ec24bfdbf840692b95fc323151` in both |
+| `urlcode-dynamic-link` | peer range | `>=0.4.0-alpha.1 <0.5.0` |
+| `urlcode-middleware` | peer range | `>=0.4.0-alpha.2 <0.5.0` |
+| `urlcode-short`, `urlcode-template`, `urlcode-docs` | exact dependency pin | `0.4.0-alpha.2` |
+
+Only `urlcode-middleware` requires `0.4.0-alpha.2` specifically: it uses the
+`middleware()` extension hook, `ExtensionActivation.root` and
+`RuntimeExtension.cacheSensitive`, none of which exist in `0.4.0-alpha.1`. The
+other extension packages work against either alpha and keep the wider floor,
+which is what the supported-floor definition below requires of them.
+
+The npm dist-tags for `@jimhoyd/urlcode` are `latest` = `0.3.0` and `alpha` =
+`0.4.0-alpha.2`. `latest` deliberately stays on the `0.3.0` Apache-2.0
+self-hosted baseline: the `0.4.0` line is a prerelease and must not become the
+default install. Every release workflow derives its dist-tag from the version
+rather than defaulting, so a prerelease can only publish under `alpha`.
+
+The sibling packages are `@jimhoyd/urlcode-ui` `0.1.0-alpha.5`,
+`@jimhoyd/urlcode-auth` and `@jimhoyd/urlcode-admin` `0.1.0-alpha.3`, and
+`@jimhoyd/urlcode-dynamic-link`, `@jimhoyd/urlcode-middleware` and
+`@jimhoyd/urlcode-short` `0.1.0-alpha.2`. For the extension line, `latest` and
+`alpha` point at the same version — see the second invariant below.
+
+Every one of those is a new version in this release. Each package's previous
+release sat at the same version number as a source tree that had moved well
+past it — 43 merged commits in `urlcode-auth`, 40 in `urlcode-ui`, 28 in
+`urlcode-admin` — so the published version number identified nothing. A
+version number that does not change when the source does is the same class of
+defect as a peer range that cannot resolve, and the rule is the same: change
+the version in the pull request that changes the source.
+
+## The supported floor
+
+The supported core floor for an extension package is the **lowest core version
+published to npm that contains every core API the extension calls**. It is a
+property of the code, not of a calendar: raise it when the extension starts
+using a core API that older published cores do not have, and not otherwise.
+
+Everything below follows from that one definition.
+
+## How a package expresses its core requirement
+
+Three forms are in use. They are not interchangeable.
+
+**Peer range (`peerDependencies`), for an extension package.** An extension is
+installed alongside core by the operator, so it must not carry its own copy;
+`peerDependencies` is the correct field. Write it as a floor plus the next
+breaking bound — `">=<floor> <0.5.0"` — where the floor is the supported floor
+above. `urlcode-auth` and `urlcode-admin` use this form.
+
+**Exact pin (`dependencies`), for an application or a starter.** A project that
+is deployed or cloned rather than composed — `urlcode-short`, `urlcode-template`,
+`urlcode-docs` — depends on one core version and pins it exactly. This is the
+right form when the repository's tests, generated files and documentation were
+all produced against one runtime and are only claimed to hold for that runtime.
+
+**Reviewed SHA (`peers.json`), for source CI on top of a range.** A reviewed
+commit is not a substitute for the peer range; it is an addition to it, used
+where the repository must build and test against an exact reviewed core
+checkout rather than whatever the registry resolves. `urlcode-auth` and
+`urlcode-admin` each keep one `peers.json` naming the reviewed core commit;
+each file states in its own `$comment` that published releases do not use those
+SHAs and resolve peers from the registry by the `package.json` range instead.
+Use a reviewed SHA when source CI needs reproducibility; do not use it to
+express what an installing operator will get.
+
+## The invariant: a published peer range must be satisfiable
+
+**A package published to npm must never declare a peer range that no published
+core version satisfies.** At publish time, at least one version on the registry
+must fall inside the range. A range that points at an unpublished core is not a
+forward-looking declaration — it is an install failure for everyone who takes
+the package from the registry.
+
+The worked example came from this project. `@jimhoyd/urlcode-middleware`
+`0.1.0-alpha.1` was published declaring `peerDependencies`
+`{"@jimhoyd/urlcode": ">=0.4.0-alpha.2"}` at a time when the registry held only
+`0.3.0` and `0.4.0-alpha.1`, so nothing satisfied it. The range was correct —
+the package genuinely needs APIs that first appear in `0.4.0-alpha.2` — so the
+fix was never to widen the range. The publication order was wrong: the package
+was published before the core it requires, and it could be installed only from
+source against a vendored core tarball carried for exactly that reason.
+
+Publishing core `0.4.0-alpha.2` resolves it without any change to the already
+published package: the range becomes satisfiable the moment core is on the
+registry. The vendored tarball and the source-only install path go away with
+it.
+
+That is what the invariant prevents, and it is the only ordering rule that
+cannot be relaxed.
+
+## The second invariant: `latest` must not fall below a sibling's floor
+
+**Where a package line publishes under a prerelease dist-tag, `latest` must
+still resolve to a version that satisfies every peer floor its siblings
+declare.** `latest` is what a plain `npm install <package>` resolves, so a
+`latest` left behind hands the installing operator a build that another
+package in the same install refuses.
+
+The worked example, again live in this project: `@jimhoyd/urlcode-auth`
+published `alpha` = `0.1.0-alpha.2` while leaving `latest` = `0.1.0-alpha.1`.
+`@jimhoyd/urlcode-admin` declares a peer floor of `>=0.1.0-alpha.2` on auth, so
+`npm install @jimhoyd/urlcode-auth` resolved a build below the floor admin
+requires. Nothing in the source is wrong; the dist-tag is.
+
+The fix is a registry operation rather than a source change:
+
+```sh
+npm dist-tag add @jimhoyd/urlcode-auth@0.1.0-alpha.2 latest
+```
+
+Core is the deliberate exception. Its `latest` stays on `0.3.0` because no
+sibling declares a floor above it — the extension packages name core through
+`peerDependencies`, which resolve by range and never by dist-tag.
+
+## A deliberate older pin is a position, not drift
+
+`urlcode-template`, `urlcode-docs` and `urlcode-short` now all pin
+`0.4.0-alpha.2`, so no downstream repository is currently behind. An older pin
+remains a legitimate position, and the rule for it does not change: it is
+recorded where a reader will meet it. The repository's README says which core
+version it pins, and every statement about runtime behavior in that repository
+is read against that version. Where a statement is only true for the pinned version, it
+says so and names the version, rather than being silently corrected to match
+core's unreleased `main`.
+
+This matters most for the trust model. Core `0.4.0-alpha.2` runs `function` and
+`middleware` routes trusted and unsandboxed by default, with `sandbox: true` as
+a per-route opt-in ([decision record](SPIKE-DEFAULT-TRUST-MODEL.md)).
+`0.4.0-alpha.1` and earlier sandbox all such code unconditionally and have no
+`sandbox` field in the schema. This is why moving a pin to `0.4.0-alpha.2` is
+a behavior change even when no YAML changes: every `function`/`middleware`
+route that does not declare `sandbox` becomes trusted on upgrade. Review those
+routes before raising a pin, and add `sandbox: true` to the ones that handle
+input or code you would not trust with full Node/filesystem/network access.
+A repository still pinned to `0.4.0-alpha.1` or `0.3.0` that documents
+sandbox-by-default is **describing its pin correctly**. Its
+generated files — field references, schemas, scaffolding output, vendored agent
+skills — are likewise correct for that pin. Divergence from core's current
+`main` is not by itself staleness, and it is not a defect to be "fixed" by
+importing behavior the pinned runtime does not have. The same point is made
+about the advisory `npm run check:downstream-skills` report in
+[release readiness](RELEASE-READINESS.md).
+
+What is a defect: a repository that does not say which core version it pins, or
+that states pin-dependent behavior as an unconditional property of URLCode.
+
+## Order of operations when core changes behavior
+
+A core behavior change reaches downstream repositories in this order. Each step
+depends on the one before it; skipping ahead is what produced the
+`urlcode-middleware` breakage above.
+
+1. **Publish core.** The version carrying the change goes to npm first. Until it
+   is on the registry, no downstream peer range may reference it (the invariant
+   above).
+2. **Raise downstream floors.** Extension packages move their peer range floor
+   to the published version; applications and starters move their exact pin.
+   A repository that chooses to stay on the older core does nothing here — that
+   is a valid outcome, and step 3 does not apply to it.
+3. **Regenerate downstream generated files.** Field references, schemas,
+   scaffolding output and vendored agent skills are regenerated *after* the
+   floor moves, against the version now pinned — never before, or they describe
+   a runtime the repository does not depend on.
+
+Reviewed-SHA repositories take the same three steps, and additionally update
+`peers.json` to the reviewed commit for the new core when source CI is expected
+to build against it. The SHA and the published floor answer different questions
+and are updated independently.
+
+## Open: two publishing conventions
+
+The repositories publish under two different conventions, and the maintainer has
+not settled which one the project uses. Both are recorded here neutrally; this
+page does not pick one.
+
+- **Private until release.** `urlcode-dynamic-link` and `urlcode-middleware`
+  keep `"private": true` in their `package.json` on `main` and drop it in the
+  release commit. Publication is an explicit, visible act in the release diff,
+  and an accidental `npm publish` from `main` fails closed. Both packages are
+  nonetheless published on npm, so the convention has been exercised.
+- **Publishable on main.** `urlcode-auth`, `urlcode-admin` and `urlcode-ui`
+  carry no `private` field and declare `publishConfig.access = "public"`
+  instead. The committed manifest is
+  the manifest that publishes, so what is on the registry can be diffed against
+  `main` without accounting for a release-only edit.
+
+The split is currently by repository, not by package kind, and nothing records
+why. Settling it is a maintainer decision; no `package.json` is changed on the
+strength of this page.

package/docs/YAML-GUIDE.md

@@ -37,7 +37,6 @@ Each page holds the recipes for one task; the section numbers continue across pa
 | [Pages, static folders and downloads](yaml/assets.md) | 10. Pages, static folders, downloads and MIME |
 | [Enable, disable and expire](yaml/conditions.md) | 11. Enable, disable and expire |
 | [Bindings, split files and tests](yaml/organization.md) | 12. Environment and secret references; 13. Split files and folders; 14. Assert inputs and outputs |
-| [Live short-link records](yaml/links.md) | 15. Live short-link records |
 | [Policies and profiles](yaml/policies.md) | 16. Hardened profile and per-route overrides |
 | [Site conventions](yaml/site.md) | 17. Site conventions |
 
@@ -56,5 +55,3 @@ Each page holds the recipes for one task; the section numbers continue across pa
 | Automatic hot updates in `serve` | Deploy/restart or use the embedding reload API deliberately |
 | “All examples are production-ready” | Validate your security, load and deployment requirements separately |
 
-Live-link recipes require `dynamicLinks: true` in the entry `urlcode.yaml`; see
-[live short-link records](yaml/links.md) and [dynamic-link opt-in](DYNAMIC-LINKS.md#explicit-project-opt-in).

package/docs/YAML-REFERENCE.md

@@ -20,6 +20,8 @@ schema-valid combinations activate successfully.
 | `routes.*.methods` | array | no | default: ["GET","HEAD"]; minItems: 1; uniqueItems: true |
 | `routes.*.methods[]` | string | no | enum: ["GET","HEAD","POST","PUT","PATCH","DELETE","OPTIONS"] |
 | `routes.*.enabled` | boolean | no | — |
+| `routes.*.sandbox` | boolean | no | default: false |
+| `routes.*.sandboxReason` | string | no | maxLength: 500 |
 | `routes.*.expires` | string | no | — |
 | `routes.*.description` | string | no | maxLength: 1024 |
 | `routes.*.parameters` | array | no | maxItems: 64 |
@@ -113,11 +115,6 @@ schema-valid combinations activate successfully.
 | `routes.*.middleware[] (option 2)` | object | no | unknown keys rejected |
 | `routes.*.middleware[] (option 2).source` | string | yes | maxLength: 1024 |
 | `routes.*.middleware[] (option 2).export` | string | no | pattern: "^[A-Za-z_][A-Za-z0-9_]*$" |
-| `routes.*.link` | object | no | unknown keys rejected |
-| `routes.*.link.collection` | string | yes | pattern: "^[A-Za-z][A-Za-z0-9_-]{0,63}$" |
-| `routes.*.link.code` | object | yes | unknown keys rejected |
-| `routes.*.link.code.from` | constant | yes | const: "path" |
-| `routes.*.link.code.name` | string | yes | pattern: "^[A-Za-z_][A-Za-z0-9_]*$" |
 | `routes.*.policies` | object | no | unknown keys rejected |
 | `routes.*.policies.profile` | string | no | pattern: "^[a-z][a-z0-9-]{0,63}$" |
 | `routes.*.policies.throttle` | one of the shapes below | no | — |
@@ -268,9 +265,22 @@ schema-valid combinations activate successfully.
 | `routes.*.auth (option 2).verified` | boolean | no | — |
 | `routes.*.auth (option 2).freshWithinSeconds` | integer | no | minimum: 1; maximum: 3600 |
 | `routes.*.auth (option 2).onDeny` | number / string | no | enum: [401,403,404,"sign-in"] |
+| `routes.*.cache` | object | no | unknown keys rejected |
+| `routes.*.cache.strategy` | string | no | enum: ["no-store","revalidate","public","immutable","swr","sie","micro","cdn-only","private"] |
+| `routes.*.cache.maxAge` | integer | no | minimum: 0; maximum: 31536000 |
+| `routes.*.cache.staleWhileRevalidate` | integer | no | minimum: 0; maximum: 31536000 |
+| `routes.*.cache.staleIfError` | integer | no | minimum: 0; maximum: 31536000 |
+| `routes.*.cache.cdnMaxAge` | integer | no | minimum: 0; maximum: 31536000 |
+| `routes.*.cache.originTtl` | integer | no | minimum: 0; maximum: 86400 |
+| `routes.*.cache.vary` | array | no | maxItems: 8; uniqueItems: true |
+| `routes.*.cache.vary[]` | string | no | minLength: 1; maxLength: 128 |
+| `routes.*.cache.statuses` | array | no | maxItems: 16; uniqueItems: true |
+| `routes.*.cache.statuses[]` | integer | no | minimum: 200; maximum: 599 |
+| `routes.*.cache.maxBytes` | integer | no | minimum: 0; maximum: 16777216 |
+| `routes.*.cache.maxEntries` | integer | no | minimum: 1; maximum: 1000000 |
+| `routes.*.cache.force` | boolean | no | default: false |
 | `includes` | array | no | maxItems: 256; uniqueItems: true |
 | `includes[]` | string | no | maxLength: 1024 |
-| `dynamicLinks` | boolean | no | default: false |
 | `policies` | object | no | unknown keys rejected |
 | `policies.profile` | string | no | pattern: "^[a-z][a-z0-9-]{0,63}$" |
 | `policies.throttle` | one of the shapes below | no | — |

package/docs/policies/cache.md

@@ -17,6 +17,19 @@ routes:
       cache: { strategy: swr, maxAge: 30, staleWhileRevalidate: 300, vary: [Accept-Language] }
 ```
 
+A route may also write `cache` directly, next to `function` or `middleware`,
+instead of nesting it under `policies`. The compiler expands it to
+`policies.cache` before anything else reads the project ([policies](../POLICIES.md)),
+so it is pure sugar over the form above and is refused alongside a direct
+`policies.cache` on the same route:
+
+```yaml
+routes:
+  /feed:
+    function: { source: feed.mjs }
+    cache: { strategy: swr, maxAge: 30 }   # same as policies: { cache: {...} }
+```
+
 ## Strategies
 
 | `strategy` | Emitted headers | Origin memory cache | Typical use |

package/examples/assets/example.yaml

@@ -3,7 +3,7 @@ description: Pages, a static directory, a download and one function next to them
 tags: [assets, static, page, download, html, files, cache, snapshot, function]
 complexity: intermediate
 capabilities: [bindings, download, enabled, function, methods, page, parameters, redirect, static]
-targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused}
+targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused, static: refused}
 routes: 5
 files: [urlcode.yaml, functions/hello.mjs, public/about.html, public/guide.txt, public/assets/example.txt, tests/requests.json, README.md]
 tests:

package/examples/aws/example.yaml

@@ -3,7 +3,7 @@ description: Native-handler project served by an AWS Lambda Function URL through
 tags: [aws, lambda, serverless, deploy, adapter, native, page, static, redirect, respond, sam]
 complexity: intermediate
 capabilities: [enabled, methods, page, parameters, redirect, respond, static]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused}
+targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused, static: refused}
 routes: 5
 services:
   - name: AWS Lambda

package/examples/cloudflare/example.yaml

@@ -3,7 +3,7 @@ description: Declarative redirect and respond project compiled into a Cloudflare
 tags: [cloudflare, workers, wrangler, compile, deploy, serverless, redirect, respond, native]
 complexity: intermediate
 capabilities: [enabled, methods, parameters, redirect, respond, response.headers]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: compatible}
+targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: compatible, static: refused}
 routes: 4
 services:
   - name: Cloudflare Workers

package/examples/conditions/example.yaml

@@ -3,7 +3,7 @@ description: Exact query, header, cookie, host and method conditions choosing be
 tags: [conditions, conditional, match, query, header, cookie, host, method, redirect, respond, disjoint]
 complexity: intermediate
 capabilities: [conditional, conditions, enabled, methods, redirect, respond]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused}
+targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused, static: refused}
 routes: 4
 grants:
   - kind: origin

package/examples/cookbook/example.yaml

@@ -3,7 +3,7 @@ description: Forty runnable routes covering every handler, middleware, inputs, b
 tags: [cookbook, reference, routes, handlers, middleware, policies, site, includes, parameters, cookies, methods, expiry, assets, everything]
 complexity: advanced
 capabilities: [bindings, download, enabled, expires, function, methods, middleware, page, parameters, policies.agents, policies.cache, policies.security, policies.throttle, redirect, request.body, respond, response.headers, static]
-targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused}
+targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused, static: refused}
 routes: 40
 files: [urlcode.yaml, routes/code.yaml, routes/redirects.yaml, routes/responses.yaml, routes/files.yaml, routes/policies.yaml, routes/middleware.yaml, route-index.json, tests/requests.json, README.md]
 tests:

package/examples/cookbook/middleware/bucket.mjs

@@ -1,5 +1,9 @@
 // Sticky A/B bucketing through a cookie, as on Vercel or Cloudflare edge examples.
 // Bucket b gets a different destination; everyone keeps their bucket for a week.
+// `Response.redirect()`'s headers are immutable (per the Fetch standard a
+// trusted route's real `Response` enforces this, unlike the sandbox's guest
+// API), so build that branch's headers up front instead of mutating the
+// result afterward.
 function cookie(request, name) {
   for (const part of (request.headers.get('cookie') || '').split(';')) {
     const [key, ...rest] = part.trim().split('=');
@@ -12,8 +16,14 @@ export default async function bucket(request, context, next) {
   const fresh = assigned !== 'a' && assigned !== 'b';
   if (fresh) assigned = Math.random() < 0.5 ? 'a' : 'b';
   context.state.bucket = assigned;
-  const response = assigned === 'b' ? Response.redirect(context.env.VARIANT_URL, 302) : await next();
+  const setCookie = 'bucket=' + assigned + '; Path=/; Max-Age=604800; SameSite=Lax';
+  if (assigned === 'b') {
+    const headers = new Headers({ location: context.env.VARIANT_URL, vary: 'cookie' });
+    if (fresh) headers.append('set-cookie', setCookie);
+    return new Response(null, { status: 302, headers });
+  }
+  const response = await next();
   response.headers.set('vary', 'cookie');
-  if (fresh) response.headers.append('set-cookie', 'bucket=' + assigned + '; Path=/; Max-Age=604800; SameSite=Lax');
+  if (fresh) response.headers.append('set-cookie', setCookie);
   return response;
 }

package/examples/cookbook/middleware/locale.mjs

@@ -1,5 +1,8 @@
 // Language redirect from Accept-Language, like Next.js i18n middleware. Only
 // languages listed in LOCALES are chosen; the native redirect is the default.
+// `Response.redirect()`'s headers are immutable (a trusted route's real
+// `Response` enforces the Fetch standard here, unlike the sandbox's guest
+// API), so that branch builds its own `Response` with headers up front.
 export default async function locale(request, context, next) {
   const supported = (context.env.LOCALES || '').split(/\s+/).filter(Boolean);
   const ranked = (request.headers.get('accept-language') || '').split(',').map((part, index) => {
@@ -8,9 +11,10 @@ export default async function locale(request, context, next) {
     return {lang: tag.trim().toLowerCase().split('-')[0], q: q ? Number(q.slice(2)) || 0 : 1, index};
   }).filter(p => p.q > 0).sort((a, b) => b.q - a.q || a.index - b.index);
   const chosen = ranked.find(p => supported.includes(p.lang))?.lang;
-  const response = chosen && chosen !== supported[0]
-    ? Response.redirect(context.env.SITE + '/' + chosen + '/welcome', 302)
-    : await next();
+  if (chosen && chosen !== supported[0]) {
+    return new Response(null, { status: 302, headers: { location: context.env.SITE + '/' + chosen + '/welcome', vary: 'accept-language' } });
+  }
+  const response = await next();
   response.headers.set('vary', 'accept-language');
   return response;
 }

package/examples/egress/example.yaml

@@ -3,7 +3,7 @@ description: A bounded HTTPS proxy route and a route with a best-effort signal,
 tags: [egress, proxy, signals, outbound, https, grant, policy, operator, webhook]
 complexity: advanced
 capabilities: [enabled, methods, parameters, proxy, respond, signals]
-targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused}
+targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused, static: refused}
 routes: 2
 grants:
   - kind: proxy

package/examples/extensions/example.yaml

@@ -3,7 +3,7 @@ description: Two declared operator extensions, one mount and two protected route
 tags: [extensions, auth, operator, mount, protected, policies.extensions, registry, revision]
 complexity: advanced
 capabilities: [enabled, extension, methods, policies.extensions, respond]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused}
+targets: {self-hosted: conditional, aws: conditional, vercel: conditional, cloudflare: refused, static: refused}
 routes: 3
 services:
   - name: operator registry

package/examples/prerender/README.md

@@ -15,8 +15,8 @@ node src/cli.ts audit --project /absolute/out --expect-routes 3
 ```
 
 The same three URLs answer identically before and after. The difference is what
-runs to serve them: the source project executes a QuickJS/WASM guest per request,
-the generated project reads a prevalidated byte buffer.
+runs to serve them: the source project runs function and middleware code per
+request, the generated project reads a prevalidated byte buffer.
 
 | | Source project | Generated project |
 |---|---|---|

package/examples/prerender/example.yaml

@@ -3,7 +3,7 @@ description: Pages rendered by a function and a template middleware, then preren
 tags: [prerender, build, static, pages, template, function, middleware, html, render]
 complexity: advanced
 capabilities: [enabled, function, methods, middleware]
-targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused}
+targets: {self-hosted: compatible, aws: refused, vercel: refused, cloudflare: refused, static: refused}
 routes: 3
 files: [urlcode.yaml, functions/page.mjs, middleware/template.mjs, prerender.mjs, tests/requests.json, README.md]
 tests:

package/examples/provider-conformance/example.yaml

@@ -3,7 +3,7 @@ description: Synthetic redirect and respond fixture deployed to a disposable env
 tags: [provider, conformance, verify, deployment, fixture, aws, vercel, cloudflare, self-hosted, probes]
 complexity: intermediate
 capabilities: [enabled, methods, parameters, redirect, request.body, respond, response.headers]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: compatible}
+targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: compatible, static: refused}
 routes: 5
 files: [urlcode.yaml, README.md]
 tests:

package/examples/vercel/example.yaml

@@ -3,7 +3,7 @@ description: Native-handler project deployed as a Vercel Node function through t
 tags: [vercel, serverless, deploy, adapter, native, page, static, redirect, respond]
 complexity: intermediate
 capabilities: [enabled, methods, page, parameters, redirect, respond, static]
-targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused}
+targets: {self-hosted: compatible, aws: compatible, vercel: compatible, cloudflare: refused, static: refused}
 routes: 5
 services:
   - name: Vercel