[collin-thomas]

What and why

Everything that ships in 1.0.0-rc.12 beyond #139, in one pull request so it is tested once. rc.12 is not published yet, so these changes are folded into its release notes (there is no [Unreleased] section).

Features and fixes

1. API routes: export default handles every method. A route's default export is the handler for each of the seven supported methods the file has no named export for. Order: named export, then HEAD derived from a named GET, then the default. OPTIONS and HEAD reach the default (so it can answer a CORS preflight); methods outside the seven still get 405. The change is in the shared dispatch (pkg/src/lib/request-execution.ts), so the dev server, bascik --server and both adapters behave the same. The language server's missing-method-handler accepts a default-only route. Docs: One Handler for Every Method.
   • Behavior change: a route that already had a default export beside its method exports now sends other methods to it instead of answering 405.
2. dev stays the Bascik dev server in the Cloudflare and Netlify templates. dev is bascik in every template; the host runtime moves to dev:cloudflare / dev:netlify (bascik --target ...). The generated AGENTS.md and the bascik and bascik-config skills tell agents never to point dev at wrangler dev or netlify dev. The shop follows the same split.
3. The pinned dev server URL stays clickable when a wrapped log line sits under it in VS Code's terminal (xterm.js joined the two rows; the banner now ends with a written space). Reproduced and tested against headless xterm.js, not in a real VS Code window.
4. bascik-config skill: a "Tune build and server performance" table (pipeline.workers, assets.symlink, http.precompress, http.cacheControl).
5. Releases page: each version's "Added / Changed / Fixed" headings get their own anchors, so the docs build no longer warns about duplicate ids.

Dependencies (replaces #140, #142, #143)

• Merges the three Dependabot branches: GitHub Actions (4 updates), production dependencies (6), dev dependencies (22).
• Not taken: @types/node 26 and @types/vscode 1.145. The types stay at the supported floors (Node 24.21, engines.vscode ^1.91.0), and dependabot.yml now ignores those two bumps.
• Lighthouse 13.6 (run by lhci 0.16) dropped the classic dom-size audit, so the 4,000 element budget reads dom-size-insight.
• Dependabot alerts 107 (glob) and 113 (minimatch): resolutions move the glob 13 and minimatch 10 copies under the Netlify CLI to 14.0.3 and 11.0.3. The expired age-gate exemptions in .yarnrc.yml are removed.
• Alert 112 (deepmerge 4.3.1, under @netlify/config) has no patched release and stays open.

Checklist

• A test fails without this change and passes with it
• yarn check:format and yarn check:spelling pass
• Docs under docs/content/ are updated when behavior changed
• CHANGELOG.md is updated (under 1.0.0-rc.12, which is unpublished)

Validation

A full local run (typechecks, checks, unit, integration, linear-time, every e2e lane, Lighthouse, extension e2e) is in progress on the combined head; results will be added here.

Known red check: the shop deploy-preview job ends without running a step on this branch (likely the shop-preview environment's branch rule); see the comment below.

🤖 Generated with Claude Code

[collin-thomas]

deploy-preview (Shop workflow) is failing, and it is not caused by this PR's changes.

The job ends about three seconds after it is created, without being assigned a runner, running a step, or producing a log. It declares environment: shop-preview, so the likely cause is that environment's deployment branch rule not allowing claude/dreamy-brown-fgnfek. That was inferred from the job's shape, not read from the settings.

The shop itself is fine on this head: the validate job in the same run passed (build, typecheck, unit, integration and e2e).

No fix is pushed for this: whether this branch may deploy a shop preview with the sandbox Stripe and Printful secrets is a repository setting. Allowing the branch in the shop-preview environment and re-running the job would clear it. The failure on the first commit (48bb574) was the same job.

---

Generated by Claude Code

[collin-thomas]

Linear-Time Checks failed on b64dbce, in a test this PR does not touch.

FAIL linear-time src/lib/linear-time.linear-time.test.ts > cost ratios > measures a run against reference work in the same process
AssertionError: expected 14.933 to be greater than or equal to 15

The other 474 linear-time tests passed. The failing line asserts referenceMs * runs >= COST_MIN_SAMPLE_MS / 2. Nothing guarantees that: costSamplesOf in linear-time.test-helper.ts stops growing runs as soon as one reference sample reaches 30 ms, then reports the fastest of the later samples. If the sizing sample included a GC pause or first-call compilation, the fastest later sample can come in under half of it, as it did here by 0.07 ms. This PR changes neither that test nor the helper, and nothing it adds runs in that test.

No fix is pushed here, to keep this PR to its own changes. A patch would either drop that lower-bound assertion (the ratio bounds below it are what the test is about) or have the helper re-check the floor against the fastest sample and grow runs again.

The CI run is still in progress, so the failed job cannot be re-run yet; I will re-run it once the run completes.

---

Generated by Claude Code

[collin-thomas]

Linear-Time Checks failed again on f494f41, in a different timing test, also untouched by this PR.

AssertionError: expected 12.560142405696228 to be less than 8
 ❯ src/typescript-service.linear-time.test.ts:132:9

That is lsp/src/typescript-service.linear-time.test.ts, "finds the page's classic scripts in linear time": extractPageScopeScripts on an input four times larger should cost about four times as much, and the limit is 8. No commit in this PR changes that scanner or the test.

Run on the same commit in a cloud container, yarn lsp:linear-time passed three times in a row (94 of 94 each time), so this looks like a noisy sample on the shared runner and not a regression in the scanner. The earlier failure on b64dbce was a different timing test in pkg (comment above), so the lane has now failed twice on this branch with two unrelated measurements.

The CI run is still in progress; the failed job will be re-run once it completes. A second failure of the same test would be treated as real.

---

Generated by Claude Code

[collin-thomas]

Replaced by #144: the same commits on the branch rc12-additions. GitHub closed this pull request when its branch was renamed.