release: v0.1.1207

[kwakayama]

Description

Cuts v0.1.1207. Ships the production fixes that landed after v0.1.1206 and are currently released to nobody.

PR	Fix
#3420	Release-asset cold loads were shed onto the client as 503, and import() never retries — one shed asset killed hydration for a whole page.
#3421	platform/compat/dynamic-import.ts leaked into the veryfront/chat client bundle; its new Function throws EvalError under the page CSP (script-src with no 'unsafe-eval') and kills hydration before first paint.
#3422	Project security.csp is now additive against a platform floor instead of replacing the whole policy.
#3419, #3418	API-reference regeneration and release-gate CI change; no runtime effect.

#3420 and #3421 are two halves of the same symptom — a project page stuck on its skeleton loaders. Neither fixes it alone: loads that shed zero assets still died on the EvalError, and loads with no EvalError still died when an asset 503'd.

Observed on a production project page, where entry module 9f1ba668… failed to import because chunk bfbed417… (the new Function helper) was refused by CSP. Reproduced from a local build of the ai-agent scaffold served under the byte-identical production CSP: the pre-fix build reports HYDRATION_FAILED with the same EvalError at the same asset and column, the post-fix build hydrates clean.

Note on #3422 landing in this version

#3422 was queued behind this PR and moved ahead of it, so it lands in v0.1.1207 rather than the version after. That is a safe order, and arguably the better one — the two are complementary:

Today, setting security.csp replaces the entire policy, and a policy naming neither script-src nor default-src leaves script loading unrestricted. Any project that set security.csp was therefore accidentally not hitting the new Function bug. #3422 makes the script-src floor always present, which means that without #3421 the eval would start being blocked for every project rather than only those on the default policy.

So #3422 would have widened the blast radius of #3421. Shipping them together is correct; shipping #3422 without #3421 would not have been.

Type of Change

• Release

Checklist

Standard three-file bump, same shape as 042f4662c (release: v0.1.1202):

• deno.json
• src/utils/version-constant.ts
• src/html/hydration-script-builder/hydration-runtime.generated.ts

Verification: deno task generate:manifests:check clean, so the committed generated runtime is what the generator emits at this version. deno fmt --check and deno lint clean. No stray 0.1.1206 in the three files. 26/26 CI checks green.

Notes for review

Publishing to npm does not by itself recover affected sites. The chain is code → npm → api dep bump → staging → prod, and a project only recovers once redeployed on a framework at or above 0.1.1207.

Worth keeping in view during rollout: a renderer below framework 0.1.1189 emits v1 asset manifests, which every newer CLI then rejects at deploy time. The deployed renderer needs to move forward with this, not be rolled back behind it.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[coderabbitai]

Warning

Review limit reached

@kwakayama, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 7 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a8ebbe8f-49fb-4653-9b7f-64d55bf55a4b

📥 Commits

Reviewing files that changed from the base of the PR and between 666bd52 and 11185ea.

⛔ Files ignored due to path filters (1)

• src/html/hydration-script-builder/hydration-runtime.generated.ts is excluded by !**/*.generated.*

📒 Files selected for processing (2)

• deno.json
• src/utils/version-constant.ts

---

_{Comment @coderabbitai help to get the list of available commands.}