@jimhoyd/urlcode 0.4.1 → 0.4.6

package/docs/READINESS.md

@@ -1,150 +0,0 @@
-# Test every route, then measure it
-
-Alpha.5 includes a local coverage gate and an assertion-aware project benchmark.
-These validate a local snapshot, not the reachability of external redirect
-services or the correctness of an entire production deployment.
-
-```sh
-urlcode routes --project ../my-links
-urlcode audit --project ../my-links --expect-routes 2
-urlcode benchmark --project ../my-links --requests 1000 --concurrency 2 --max-p95-ms 50
-```
-
-All three activate/validate the project with the same runtime that serves it --
-each route in its own declared trust mode, trusted in-process unless it declares
-`sandbox: true` -- and use local environment loading like `test`. Pass an
-external `--policy` for explicitly authorized bindings. No destination redirects are followed, credentials are not
-printed, and no remote load-test target is accepted.
-
-## Inventory and count reconciliation
-
-`routes` reports each configured route's pattern, handler, exact allowed methods,
-execution mode (`sandbox`, with `sandboxReason` when the route declares one)
-and active/disabled/expired state. It includes routes from YAML includes. A
-parameter pattern is one route; its possible URLs are not a finite route count.
-A static mount is one route, even when it contains many files.
-
-`routes --compare previous.json` diffs the current inventory against a saved
-`routes` report: added, removed and changed routes (handler, methods, state,
-execution mode and its reason, middleware count, policies, generated marker and
-the policy description). A route that flips between trusted and sandboxed
-execution is a change, including when its handler is native and only its
-middleware runs project code. It
-prints JSON, or Markdown tables with `--format markdown`, and always exits 0;
-it reports, it does not judge. The [GitHub action](CI.md) posts this diff on
-pull requests.
-
-`audit --expect-routes N` compares N with the total configured count. Its summary
-separately counts active, disabled and expired routes and groups by handler.
-A mismatch exits nonzero. Keep N reviewed in your application CI so accidentally
-removing a route cannot silently reduce the test workload. Change it intentionally
-when adding/removing routes; do not calculate the expected value from the same YAML.
-
-## Generated checks plus explicit examples
-
-The audit generates GET/HEAD checks for concrete native redirects, declared
-responses, pages/downloads and every snapshotted static file. It checks status,
-redirect Location, file metadata/length and declared bodies where applicable.
-It also checks literal disabled/expired routes for 404/410. Generated checks are
-contract consistency checks; they cannot decide whether your intended destination
-or content is correct. Keep independent expected outcomes in fixtures too.
-
-Functions, parameterized routes, required inputs/bodies and non-GET/HEAD methods
-need fixtures in `tests/requests.json`:
-
-```json
-[
-  {"path":"/hello/Ada","status":200,"expectBody":"{\"message\":\"Hello, Ada!\"}"},
-  {"path":"/hello/Ada","method":"HEAD","status":200,"expectBody":""},
-  {"path":"/go","status":302,"expectHeaders":{"location":"https://example.com/"}},
-  {"path":"/go","method":"POST","status":405,"expectHeaders":{"allow":"GET, HEAD"}},
-  {"path":"/missing","status":404}
-]
-```
-
-Each case may supply `method`, string-valued `headers`, a text `body`, expected
-`status`, string-valued `expectHeaders`, and exact UTF-8 `expectBody`. Status is
-required. A passing case needs at least one body/header assertion to count toward
-coverage; status-only successes appear in `unassertedCases`. Choose assertions
-that verify your intended business result, not just a generic header. Fixtures
-are limited to 10,000 cases/16 MiB; checked response bodies to 16 MiB. Requests have
-10-second transport timeouts. Failures do not stop subsequent checks. Status 0
-means a transport/response-limit failure. Output reports case numbers/statuses,
-not response bodies, header values or fixture URLs that may contain private data.
-
-Coverage uses the route that actually matched. A literal route shadowing a
-parameter example cannot count toward parameter coverage. Each active route and
-allowed method needs a passing normal response (below 400); an intentionally
-error-valued native `respond` check can cover its declared outcome. A negative
-fixture alone cannot prove a function works normally. Disabled/expired routes
-are counted separately and excluded from active coverage requirements. Inactive
-parameter patterns still need explicit negative fixtures to exercise them.
-
-`ready: true` requires a nonempty active project, matching expected count (when
-supplied), zero failed checks and no uncovered active route/method combinations.
-It means this local gate passed, not that all branches, parameter values or assets
-have independent business assertions. Function routes intentionally serving only
-errors cannot satisfy normal-response coverage in this release. Time-dependent
-expiry is evaluated at audit start; avoid running a gate exactly at expiry.
-
-`urlcode test` runs only explicit fixtures. `audit` adds generated native checks,
-counts and coverage. Both execute locally and never follow redirect destinations.
-Audits run sequentially to avoid mistaking worker saturation for a routing failure.
-
-## Benchmark your actual project
-
-The benchmark cycles generated checks and explicit successful GET/HEAD fixtures.
-POST/PUT/PATCH/DELETE/OPTIONS and expected error cases are excluded. Function
-GET/HEAD handlers still execute: use synthetic test data and reviewed bindings.
-The workload is case-weighted, not a simulation of real user traffic. A short run
-may not reach every case; compare `exercisedWorkloadCases` with `workloadCases`.
-
-Output includes requested/completed count, assertion failures, status histogram,
-startup time, throughput, p50/p95/p99 response time, process RSS, Node and OS.
-Any wrong status/header/body, incomplete run or exceeded `--max-p95-ms` budget
-exits nonzero. Warmup is zero and is reported explicitly. Client/server share one
-process; RSS and latency are local measurements, not server-only production SLAs.
-
-Defaults: 1,000 requests, concurrency 2, 30-second scheduling budget. Bounds:
-1–100,000 requests, 1–32 concurrent requests, `--seconds` 1–300. In-flight requests
-may finish after the scheduling budget, bounded by their timeout. Higher function
-concurrency can legitimately cause 503 because the default pool has two workers.
-Choose a latency budget from repeatable measurements on your intended host.
-The existing synthetic `npm run benchmark -- 10000` is still a separate scale test.
-
-## What a release should prove
-
-| Check | Evidence to require |
-|---|---|
-| Counts and coverage | Reviewed expected count; every active route/method covered; disabled/expired routes accounted for |
-| Correct happy paths | Exact redirect destinations/status/query handling; function bodies/headers; representative parameter and asset examples |
-| Invalid inputs | Missing/duplicate/wrong-type inputs; malformed paths/encoding; wrong methods; bad JSON/media type; oversized bodies |
-| Response contracts | HEAD empty bodies, Allow headers, cookies, cache policy, download names/MIME; ETag/304 and range/206/416 fixtures |
-| Configuration changes | Invalid candidate keeps last-good routes; valid reload updates behavior; removed routes are intentional |
-| Code containment | Runtime security suite passes; no ambient filesystem/network access; grants narrow and revision-pinned |
-| Capacity and failure | Representative mix and concurrency; low errors and repeatable latency; timeouts, overload recovery and memory over sustained runs |
-| Deployment | Fresh install; real HTTPS/domain/health smoke; rollback; shutdown; logs/alerts; explicitly authorized destination reachability checks |
-
-The runtime suite covers many generic protocol/security/reload cases. Apps must
-supply their own business and boundary fixtures. Automated remote destination
-health, redirect-chain/loop analysis, DNS/TLS checks, sustained soak/load profiles,
-coverage by function branch and historical performance comparison remain planned.
-Run the local audit in CI now (the [project action](CI.md) wires validate, test,
-audit and the route diff into GitHub pull requests); do not label a passing local
-audit “production certified.”
-Once a candidate is deployed, `urlcode verify-deployment --target` compares its
-responses with this project; see [deployment checks](DEPLOYMENT-CHECKS.md).
-
-Before writing fixtures, `urlcode explain /route` shows what the compiled
-configuration will do for a path: effective methods, the handler, the middleware
-chain, validated inputs, the policies in effect and the cache outcome, so a
-fixture asserts declared behavior rather than a guess. `urlcode manifest --json`
-(also written by `build` as `manifest.json`) lists every route, the capabilities
-in use, external requirements and per-target support with the revision digest,
-which is the document to attach to a release review. Both read the
-configuration only; they are not evidence that a deployment serves it.
-
-Routes with middleware need explicit request fixtures with meaningful response
-assertions for every active method. Audit cannot infer their behavior from the
-underlying redirect or asset handler, so it does not generate native checks for
-those routes. The route inventory includes a middleware count.

package/docs/README.md

@@ -1,87 +0,0 @@
-# URLCode documentation
-
-Start with [the framework](FRAMEWORK.md): the four packages, the ladder from
-redirects to a full application, the composition contract and the rules an AI
-agent must follow. [Project direction](PROJECT-DIRECTION.md) states the
-boundary and the license. Use documentation pinned to your runtime revision;
-`version: "1"` is the stable project-format contract for this release line.
-
-## Author a project
-
-| Goal | Start here |
-|---|---|
-| Install the CLI | [Installation](INSTALL.md) |
-| Write YAML with examples | [YAML guide and recipes](YAML-GUIDE.md) |
-| Look up every accepted field | [Generated field reference](YAML-REFERENCE.md), [JSON Schema](../schemas/urlcode.schema.json) |
-| Let an AI build routes | [AI authoring guide](AI-AUTHORING.md), [llms.txt](../llms.txt) |
-| Load authoring/operations rules into an agent | [Authoring skill](../.claude/skills/urlcode-authoring/SKILL.md), [operations skill](../.claude/skills/urlcode-operations/SKILL.md), [how they are distributed](AI-AUTHORING.md#agent-skills) |
-| Run examples | [25-route cookbook](../examples/cookbook/README.md), [prerender recipe](../examples/prerender/README.md), [small starter](STARTERS.md) |
-| Understand exact behavior | [Specification](SPECIFICATION.md), [routing](ROUTING.md), [HTTP](HTTP.md) |
-| Run examples | [40-route cookbook](../examples/cookbook/README.md), [prerender recipe](../examples/prerender/README.md), [small starter](STARTERS.md) |
-| Let an AI build routes | [The framework](FRAMEWORK.md), [AI authoring guide](AI-AUTHORING.md), [llms.txt](../llms.txt), [SDK and read-only MCP](TOOLING.md) |
-| Reuse code around routes | [Middleware](MIDDLEWARE.md), [middleware examples](MIDDLEWARE-EXAMPLES.md) |
-| Handle secrets and decide what to sandbox | [Function security](FUNCTION-SECURITY.md) |
-| Author guest functions in TypeScript | [Build-time guest transpilation](TYPESCRIPT-AUTHORING.md) |
-| Serve pages, files and downloads | [Assets](ASSETS.md) |
-| Publish a site with no request-time guest code | [Prerendering helper and recipe](PRERENDER.md) |
-| Select response branches | [Exact conditions](CONDITIONS.md) |
-| Proxy an API or emit a webhook | [Bounded egress and operator grants](EGRESS.md) |
-| Throttle, block agents, set security headers, compress or cache | [Policies](POLICIES.md): [throttle](policies/throttle.md), [agents](policies/agents.md), [security](policies/security.md), [compression](policies/compression.md), [cache](policies/cache.md) |
-| Generate robots.txt, sitemap.xml, favicon, security.txt and llms.txt | [Site conventions](SITE.md) |
-| Organize YAML across folders | [Organization](ORGANIZATION.md), [readability practices](BEST-PRACTICES.md) |
-| Generate placeholders from YAML | [Scaffolding](SCAFFOLDING.md) |
-| Convert provider redirect files | [Strict interchange and conversion reports](INTERCHANGE.md) |
-| Import thousands of redirects | [Bulk import and scale evidence](BULK.md) |
-| Reuse local project recipes | [Recipe catalog](RECIPES.md) |
-| Check declared configuration against standards-referenced rules | [Compliance](COMPLIANCE.md) |
-
-## Extend the runtime
-
-| Goal | Start here |
-|---|---|
-| Add accounts, sign-in and protected routes | [urlcode-auth](../packages/auth#readme), [auth security](../packages/auth/SECURITY.md) |
-| Manage users, sessions, roles and audit | [urlcode-admin](../packages/admin#readme) |
-| Restyle every extension page and translate copy | [urlcode-ui](../packages/ui#readme), [ui contract](../packages/ui/CONTRACT.md) |
-| Write or install a versioned extension | [Extensions](EXTENSIONS.md), [example fixture](../examples/extensions/README.md) |
-| Follow implementation of the auth, admin and UI extensions | [Extension implementation sequence](archive/2026-09-19/EXTENSION-IMPLEMENTATION.md) |
-| Know which core version an extension package supports, and how it says so | [Core version alignment](VERSION-ALIGNMENT.md) |
-| Add host behavior in operator code | [Plugins](PLUGINS.md) |
-| Use the API from TypeScript | [TypeScript: shipped declarations, exports, build and fidelity](TYPESCRIPT.md) |
-
-## Operate and deploy
-
-| Goal | Start here |
-|---|---|
-| Work locally | [Local development](LOCAL-DEVELOPMENT.md), [tunnels](TUNNELS.md) |
-| Prove responses and counts | [Readiness](READINESS.md) |
-| Check pull requests of a project on GitHub | [CI action, route diffs and the starter workflow](CI.md) |
-| Deploy and roll back | [Operations](OPERATIONS.md) |
-| Review security findings and gaps | [Internal security audit](SECURITY-AUDIT.md) |
-| Assess release readiness | [Evidence and open gates](RELEASE-READINESS.md) |
-| See unfinished work | [Roadmap](../ROADMAP.md) |
-| Read why per-route Lambda compilation was declined | [Lambda compile spike (archived)](archive/2026-09-19/SPIKE-LAMBDA-COMPILE.md) |
-| Verify a running deployment matches the project | [Deployment checks](DEPLOYMENT-CHECKS.md) |
-| Inspect target support | [Capabilities and normalized representation](CAPABILITIES.md) |
-| Deploy to Vercel, AWS Lambda or Cloudflare Workers | [Vercel](VERCEL.md), [AWS](AWS.md), [Cloudflare](CLOUDFLARE.md), [provider verification evidence](PROVIDER-VERIFICATION.md) |
-| Watch a deployment | [Monitoring](MONITORING.md), [observability](OBSERVABILITY.md) |
-| Estimate concurrency and memory | [Capacity and limits](CAPACITY.md), [measurements](PERFORMANCE.md), [load testing](LOAD-TESTING.md) |
-| Prepare for overload, DDoS and recovery | [Resilience playbook](RESILIENCE.md) |
-
-## Direction and evidence
-
-Start with [principles and open decisions](OPEN-DECISIONS.md) for a plain-language
-review and [the roadmap](../ROADMAP.md) for next work. Current behavior belongs
-in the guides above and the [specification](SPECIFICATION.md).
-
-- [Release readiness](RELEASE-READINESS.md), [security audit](SECURITY-AUDIT.md),
-  [sandbox review](SANDBOX-REVIEW.md) and [provider evidence](PROVIDER-VERIFICATION.md)
-  distinguish implementation from evidence still missing.
-- [Version alignment](VERSION-ALIGNMENT.md) and [release security](RELEASE-SECURITY.md)
-  describe peer compatibility and publication.
-- Open proposals: [middleware layering](SPIKE-CORE-LAYERING.md),
-  [agent benchmark](SPIKE-AI-FRAMEWORK-BENCHMARK.md), and
-  [business suite](SPIKE-BUSINESS-SUITE.md). None is an implementation promise.
-- [Historical plans and reviews](archive/README.md) are archived separately.
-
-Examples are educational unless backed by runnable fixtures. Infrastructure
-limits are deployment settings, not fields to invent in route YAML.

package/docs/RECIPES.md

@@ -1,99 +0,0 @@
-# Local recipes
-
-Recipes are ordinary version-controlled URLCode projects shipped with the
-runtime. There is no network registry, install script, provider account or
-project-code execution during authoring. Search them before writing a common
-route by hand: the catalog is the vocabulary of behavior the runtime already
-supports, and every recipe validates, tests and audits.
-
-```sh
-urlcode recipes list
-urlcode recipes search "webhook json"        # id, description, tags, capabilities
-urlcode recipes search webhook --json
-urlcode recipes show webhook-receiver        # metadata first, then every file
-urlcode recipes add webhook-receiver --out ./orders-hook --dry-run
-urlcode recipes add webhook-receiver --out ./orders-hook
-urlcode validate --local --project ./orders-hook
-```
-
-## The catalog
-
-| Recipe | Complexity | What it shows | Needs |
-|---|---|---|---|
-| `redirect` | starter | Permanent redirect forwarding one allowlisted query key | nothing |
-| `health-page` | starter | Native `/health` text and `/status` JSON, no-store | nothing |
-| `json-api` | starter | Bounded JSON body echoed by a sandboxed function | self-hosted runtime |
-| `webhook-receiver` | starter | JSON event with a type header, shape-checked, `202` | self-hosted runtime |
-| `typescript` | intermediate | Typed guest transpiled by `build-typescript` | build step |
-| `static-plus-api` | intermediate | Page, static directory and one JSON function | self-hosted runtime |
-| `cors-api` | intermediate | Preflight and CORS headers from route middleware | self-hosted runtime |
-| `contact-form` | intermediate | Validated message, fixed signal to a hook after the response | signal grant (`--policy`) |
-| `middleware` | advanced | Fourteen reusable middleware patterns ([described here](MIDDLEWARE-EXAMPLES.md)) | self-hosted runtime |
-| `authenticated-json-api` | advanced | Function behind `auth: true` | operator auth extension, `--host-file`, `--origin` |
-| `protected-download` | advanced | Native attachment behind `auth: true` | operator auth extension, `--host-file`, `--origin` |
-
-Each recipe contains a README, `tests/requests.json` and editable files.
-Replace example destinations and review the resulting files before use. The
-authenticated recipes declare `extensions.auth` and protect their route with
-the short form described in [extensions](EXTENSIONS.md); their README shows the
-minimal host-file fixture that reproduces the bundled tests. Nothing in the
-catalog verifies webhook signatures: the sandbox has no crypto or network API,
-so signed webhooks belong behind an operator extension or a trusted host.
-
-## `recipe.yaml`
-
-Every recipe carries `recipe.yaml`, validated against
-[`schemas/recipe.schema.json`](../schemas/recipe.schema.json) by `npm run check`:
-
-- `id`, `description`, `tags`, `complexity` (`starter`, `intermediate`,
-  `advanced`): written by hand; `search` matches id, description, tags and
-  capabilities, every word must match, and whole-tag or id hits rank first.
-- `capabilities`, `targets`, `routes`: derived from the capability preflight
-  (`analyzeProjectCapabilities` per target after site expansion). The check
-  refuses a hand-edited value that differs, so a recipe cannot claim a target
-  it does not activate on. `targets` is `compatible`, or the strongest issue
-  (`conditional`, `unknown`, `refused`); `routes` is the `--expect-routes` value.
-- `services` (external services), `grants` (operator grants, never from project
-  files), `inputs` (what to edit), `files` (the copy list), `tests` (fixtures
-  and the exact commands) and `behavior` (one observable statement per line).
-
-`show` prints this metadata before the file contents so a reader sees what a
-recipe needs before its files scroll past; `--json` returns the same object with
-a `content` map. `list` prints one line per recipe, or the metadata with `--json`.
-
-## Examples
-
-`examples/*/example.yaml` uses the same schema, and `urlcode examples search
-<text> [--json]` returns the smallest matching runnable example first with the
-file to read. The cookbook's forty routes are indexed per route in the generated
-[`examples/cookbook/route-index.json`](../examples/cookbook/route-index.json)
-(handler, methods, capabilities, policies and middleware module names as tags;
-`npm run docs:cookbook-index` regenerates it and `npm run check` refuses a stale
-copy), so a search for `etag` answers the cookbook and its `/versioned` route.
-Entries without a `urlcode.yaml` (operator rules, monitoring configuration,
-scripts) are `runnable: false` and carry no derived fields.
-
-## Adding a recipe
-
-`add` creates a new standalone directory. It refuses an existing destination,
-even an empty directory; it never merges or overwrites existing project routes.
-Review or copy selected declarations manually when combining projects. Dry-run
-reads and validates the packaged recipe and checks the destination, but writes
-nothing. The output parent must already exist and be owned by the caller.
-Dependencies are written first and the complete `urlcode.yaml` is published by
-rename last. A failed write removes the new directory. This is atomic project
-activation, not an atomic directory replacement or a guarantee against a local
-attacker concurrently replacing the caller's output directories.
-
-## SDK and MCP
-
-The SDK provides `listRecipes()`, `searchRecipes(text)`, `showRecipe(name)`,
-`addRecipe(name, output, {dryRun})`, `listExamples()` and `searchExamples(text)`.
-Catalog names are a fixed list in code; metadata and file lists come from each
-schema-checked `recipe.yaml` and are returned as copies. Unknown names and
-arbitrary paths/URLs fail closed. The stdio MCP server adds `search_recipes` and
-`search_examples` beside `recipes_list` and `recipes_show`
-([tooling](TOOLING.md)). Integration tests run every recipe through the real
-runtime with its fixtures and audit it with its declared route count (after
-building the TypeScript recipe, with a fixture registry for the authenticated
-ones and the generated policy for the contact form).

package/docs/RELEASE-0.4.0-alpha.3.md

@@ -1,50 +0,0 @@
-# Coordinated 0.4.0-alpha.3 release
-
-This release prepares core, UI, auth and admin at `0.4.0-alpha.3`, as explicitly
-selected by the maintainer. The shared number identifies this tested package
-set; it does not enable permanent fixed versioning or leave the alpha channel.
-Existing versions, tags, and npm `latest` channels are preserved.
-
-## Included changes
-
-Core includes the monorepo consolidation, corrected Windows npm invocation,
-current trust-by-default authoring guidance, and support for a TypeScript module
-shared by trusted and sandboxed routes without weakening the sandbox checks.
-The CLI and MCP report the new runtime version. The runtime remains independent
-of the extension implementations.
-
-Auth includes deterministic worker cleanup on rejected initialization and
-Windows backup flushing. Auth/admin refresh a lifecycle hook's entry module on
-each activation; changes to the entry module's own imports still require restart.
-The extension changelogs record their package-specific changes.
-
-All four packages use the shared release coordinator, immutable release tags,
-exact-commit full verification, retained retry artifacts and trusted npm
-publication. The candidate rehearsal installs their tarballs together outside
-the workspace and checks peers, public imports and scaffolding.
-
-## Installation and compatibility
-
-Once publication has completed, install an exact, coordinated set in the
-consumer application's directory:
-
-```sh
-npm install --save-exact @jimhoyd/urlcode@0.4.0-alpha.3 @jimhoyd/urlcode-ui@0.4.0-alpha.3 @jimhoyd/urlcode-auth@0.4.0-alpha.3 @jimhoyd/urlcode-admin@0.4.0-alpha.3
-```
-
-Applications only need the extensions they actually use; admin requires auth
-and UI, and auth requires UI. Auth/admin peer floors for this release are
-`>=0.4.0-alpha.3 <0.5.0`. Update their dependencies together when crossing from
-the former `0.1.x` extension line. Commit the resulting lockfile and use `npm ci`
-in deployment. This release changes package peer compatibility intentionally;
-it does not imply all previously mixed versions are supported.
-
-Publication order is core, UI, auth, admin. A partial release stops before the
-next package; diagnose and rerun its original workflow without moving tags.
-The standalone template remains an exact core consumer and is updated through
-its own PR after core is published. Archived extension repositories are not
-publication targets.
-
-CI and candidate success are not independent security assessment, live-provider
-acceptance, or operational recovery proof. The intermittent Windows startup
-timeout remains tracked in #202.

package/docs/RELEASE-0.4.1.md

@@ -1,73 +0,0 @@
-# URLCode 0.4.1
-
-Core, UI, auth and admin share this explicitly selected stable version. This does not enable permanent fixed versioning. Internal peer minimums advance to this version; install the coordinated set together.
-
-```sh
-npm install --save-exact @jimhoyd/urlcode@0.4.1 @jimhoyd/urlcode-ui@0.4.1 @jimhoyd/urlcode-auth@0.4.1 @jimhoyd/urlcode-admin@0.4.1
-```
-
-This coordinated release moves core, UI, auth and admin from `0.4.0-alpha.3` to stable `0.4.1`. It makes the reviewed monorepo release line available through npm `latest` and keeps the four packages' peer minimums aligned.
-
-The runtime retains its existing trust model: project functions and middleware run trusted in Node by default; routes declaring `sandbox: true` retain QuickJS/WASM isolation. The stable label is a distribution decision, not an independent security assessment or hostile multi-tenant readiness claim.
-
-Release preparation now supports an explicit exit from alpha. Publication promotes the exact signed candidate archives, pins their manifest digest in immutable tags, checks actual npm installability, and updates the standalone starter to the published core version. Historical alpha versions and tags remain unchanged.
-
-### admin-kit-only-console.md
-
-**Breaking:** the console renders only through the urlcode-ui kit. `ui` is now a
-required option of `adminExtension` and of `createAdministrationRuntime`'s
-`admin` block, which is itself no longer optional.
-
-`@jimhoyd/urlcode-ui` was already a required peer dependency, so nothing new has
-to be installed. What changed is that the `ui` *extension* must now be supplied
-and active: the primitive render path — the same `admin/*` templates rendered
-through the shared primitives inside a console shell admin built itself — is
-gone, along with the `RenderPath` seam, the `activeKit()` helper, the
-`ScreenOptions.shell.sidebar` markup and `src/admin-presentation.ts`. The kit
-builds the sidebar, page header and skip target from the `nav` items and account
-`menu` admin supplies, so the console shell has one representation instead of
-two. `ScreenOptions.preferences` is gone too: the kit layout now renders through
-the same resolved presentation as the body, so the document's `lang` matches the
-copy on the page.
-
-Activation refuses up front, rather than failing per request in production, when
-
-- `ui` is missing,
-- `ui` is supplied but not active yet — declare `ui` before `admin` under
-  `extensions` in `urlcode.yaml`, since the runtime activates in declaration
-  order, and mount its assets route, or
-- the kit was built without `adminUiTemplates`.
-
-To migrate, build the extension with admin's templates and pass it:
-
-```js
-const ui = createUiExtension({projectSha256, projectRoot, sources: [authCatalogue], extensions: [authUiTemplates, adminUiTemplates]});
-adminExtension({service, csrfKey, projectSha256, ui});
-```
-
-Scaffolding emits that wiring for you: `scaffold()`, `initAdministration` and
-`urlcode init --with ui,auth,admin` compose the kit and register the admin
-templates with it. `ui` is now required, and must come before `admin`; the
-scaffold refuses otherwise before writing anything.
-
-### auth-kit-only-render.md
-
-Breaking: the `ui` extension is now required. Every account screen renders through the `urlcode-ui` kit; the shared-primitive fallback is gone. `authExtension({ui, ...})` refuses activation when `ui` is absent or when the runtime has not activated it, naming the missing piece instead of failing per request. Declare `ui` before `auth` in `urlcode.yaml` (with its asset route) and list `ui.registration` before `authExtension` in the host: the runtime activates extensions in the order `urlcode.yaml` declares them. `@jimhoyd/urlcode-ui` was already a required peer dependency, so nothing new needs installing; what changes is that the extension must be supplied and active. `ScreenOptions.ui` is no longer optional and `screenObserver` no longer reports a render path.
-
-Scaffolding composes the kit for you: `urlcode init --with ui,auth` and the standalone `initAuthentication` now write a project whose `urlcode.yaml` declares `ui` first and whose host passes it to `authExtension`. The scaffold refuses when `ui` is missing, or ordered after `auth`, before anything is written.
-
-### auth-store-startup-diagnostics.md
-
-Report which startup phase an auth store worker reached when its 15-second bound elapses, and reject at once when the worker fails or exits before reporting readiness instead of waiting the bound out. The status and code are unchanged; the detail is attached as the error's cause for operator logs and never reaches a response.
-
-### pin-generated-site-dependencies.md
-
-`urlcode-auth init` now writes a `package.json` that pins this package and each declared peer at the exact version installed beside it, instead of a manifest with no dependencies at all; `initAuthentication` returns those pins and names any peer it could not resolve. Nothing is installed: running `npm install` in the generated directory to produce a lockfile stays the operator's explicit step, and no upgrade command exists.
-
-### ui-scaffold-peer-registration.md
-
-The scaffold wires kit-rendering peers into the host it generates. `scaffold()` reads the composed `names` and emits `createUiExtension({..., sources: [authCatalogue], extensions: [authUiTemplates, adminUiTemplates]})`, importing each peer it needs, so `urlcode init --with ui,auth,admin` produces a project that activates. Previously it always wrote `sources: []` and no `extensions`, which left auth and admin without their copy and templates. `ui` alone still registers nothing and imports no peer.
-
-Name `ui` first: the runtime activates extensions in the order `urlcode.yaml` declares them, core writes that file in `--with` order, and auth and admin both refuse to activate before the kit is active.
-
-Publish to the npm `latest` channel in core → UI → auth → admin order after exact-commit CI and candidate verification. Existing tags and the `alpha` channel stay unchanged; this stable release advances `latest`. Changesets prerelease mode is exited. Update the standalone starter's exact core pin after registry installability is verified. This preparation is not evidence of publication or an independent security assessment.

package/docs/RELEASE-READINESS.md

@@ -1,117 +0,0 @@
-# Release readiness
-
-Status: `0.4.0-alpha.2` (`package.json`) alpha of the extension contract and
-agent tooling on top of the `0.3.0` self-hosted release; `0.4.0-alpha.1` is the
-most recent alpha actually published; the npm dist-tags for `@jimhoyd/urlcode`
-were `latest` = `0.3.0` and `alpha` = `0.4.0-alpha.1` when checked against the
-registry on 2026-09-19, so the repository's `0.4.0-alpha.2` is unpublished (see
-"Packaging" below). Production approval remains specific to
-the workload and deployment environment.
-This register describes the current public runtime, not future promises.
-Use the contract and docs from the same pinned commit as your installed runtime.
-
-## What is aligned
-
-- One portable YAML project, explicit includes, one handler per route (redirect, respond, page, static, download, function, proxy, conditional or extension),
-  per-route middleware and consistent request/response validation.
-- One starter with a function route first and an ordinary redirect second.
-  Clone urlcode-template or use `urlcode init`; neither requires a database.
-- Native handlers avoid user-code execution unless middleware is attached.
-- Functions/middleware run trusted and unsandboxed by default (in-process,
-  full Node access); `sandbox: true` opts a route into isolated QuickJS/WASM
-  with no ambient filesystem, network or Node APIs (docs/SPIKE-DEFAULT-TRUST-MODEL.md).
-  Host bindings require external revision-pinned approval either way.
-- The runtime is released under Apache-2.0.
-
-## Regression evidence
-
-`npm run verify` is the lint, syntax/schema-reference and unit/HTTP regression gate.
-`npm run test:package` installs the packed artifact and exercises initialized apps,
-route audits, bounded benchmarks and assets. On a push to `main`, CI runs Node
-22/24/26 on Linux/macOS/Windows (nine combinations) and tests the container
-under resource restrictions; a pull request runs the same Node versions on
-Linux only (`.github/workflows/ci.yml`'s matrix), with the macOS/Windows legs
-deferred to the post-merge run.
-
-| Area | Covered behavior | Practical limit |
-|---|---|---|
-| Routing and HTTP | Exact/parameter/static precedence, methods, inputs, assets, middleware and response assertions | Stable 0.1 contract; unsupported semantics reject rather than emulate |
-| Isolation | `sandbox: true` capability/permission boundaries, deadlines, memory and invalid outputs; the trusted default's grant scoping | Not an independent security assessment or multi-tenant service certification; trusted-route code safety is the project's own call |
-| Overload | Function pool queue caps; HTTP admission saturation, separate bounded probe budget, health availability and recovery after upload completion/disconnect | 64 application requests default; no fairness, upstream DDoS protection or end-to-end deadline |
-| Worker replacement | Repeated guest deadlines shed load and the pool returns to service after backoff, rather than latching off for the life of the process | Bounded by the configured worker count; no cross-process load balancing |
-| Shutdown | New work rejects; repeated close shares completion | Existing deadlines can still fail during shutdown |
-| Activation/recovery | Invalid reload retains last-good snapshot; corrupt revision metadata rejects activation | No deployment orchestration |
-| Packaging | Packed installation and starter examples tested; sensitive files excluded | `0.3.0` and `0.4.0-alpha.1` are published to npm as `@jimhoyd/urlcode` (`latest` and `alpha` dist-tags respectively; dist-tags verified against the npm registry on 2026-09-19, when the repository stood at the unpublished `0.4.0-alpha.2`). Published extension packages on the same date: `@jimhoyd/urlcode-auth@0.1.0-alpha.2`, `@jimhoyd/urlcode-admin@0.1.0-alpha.2`, `@jimhoyd/urlcode-ui@0.1.0-alpha.4`. (`@jimhoyd/urlcode-short@0.1.0-alpha.1`, `@jimhoyd/urlcode-dynamic-link@0.1.0-alpha.1` and `@jimhoyd/urlcode-middleware@0.1.0-alpha.2` were also published on that date, then retired and unpublished later the same day; all three repositories were deleted. Middleware's withdrawal removed no capability — per-route middleware is native to core.) Observed in passing on that date: auth's dist-tags were split — `alpha` at `0.1.0-alpha.2` while `latest` lagged at `0.1.0-alpha.1`, so a plain `npm install @jimhoyd/urlcode-auth` resolved a build below admin's declared floor. That is resolved: auth and admin both read `latest` = `alpha` = `0.1.0-alpha.3`. `@jimhoyd/urlcode-ui` now carries a split of its own — `alpha` = `0.1.0-alpha.6`, `latest` = `0.1.0-alpha.5` — which is deliberate rather than drift, and safe only because admin's ui floor is exactly `>=0.1.0-alpha.5`. See [VERSION-ALIGNMENT.md](VERSION-ALIGNMENT.md). GitHub Releases attach a Homebrew formula (`urlcode.rb`) for manual copy into a tap, not an automated Homebrew Core/tap publish. No provider adapter guarantee. |
-
-`npm run check:downstream-skills` is a manual, advisory report worth running
-before a release: it diffs core's `.claude/skills/` copies against copies
-vendored by downstream repositories (currently `urlcode-template`) when that
-repository is cloned as a sibling checkout, and prints how many lines differ
-per skill. It never fails and never asserts which side is correct -- a
-downstream repo commonly pins an older published core version, and
-divergence from core's current `main` can be the *correct* reflection of
-that pin rather than staleness (see issue #155). It is not part of `check`
-or `verify` because it depends on an out-of-repo sibling checkout that
-normal CI does not have; it is a prompt to review the diff against the
-downstream pin, not a pass/fail gate.
-
-`npm audit --omit=dev` now runs in CI and fails the build on any runtime advisory;
-development-only advisories are reported without blocking. Dependabot proposes npm,
-GitHub Actions and base-image updates weekly. Actions and the container base image
-are pinned by immutable SHA/digest, so a rebuild cannot silently change the runtime.
-A passing audit is a dated check against known advisories, not proof of safety.
-
-## Gates before production approval
-
-These remain open. Record workload, runtime/app/image revisions, environment,
-commands, results and owner for each exercise; do not convert a passing local
-benchmark into a universal throughput claim.
-
-1. Independent review of host/sandbox boundaries.
-2. Sustained load and soak on intended hardware, through the actual TLS/proxy
-   path: successful throughput, tail latency, 503/504 rate, RSS and recovery.
-   `urlcode benchmark --target` measures a running deployment through its real
-   path and separates shed responses from transport errors; see
-   [load testing](LOAD-TESTING.md). The tool is GET/HEAD only and caps at 300
-   seconds, so it does not by itself close this gate.
-   Include mixed native/function workloads and slow peers.
-3. Kill/restart, resource exhaustion and rolling deployment/rollback
-   exercises with the chosen supervisor and ingress. A future durable-state
-   extension needs its own backup/restore drill; core has no durable store.
-4. Alerting and ownership for sustained errors, latency, readiness, dropped logs,
-   disk space, restarts and backups. Pick service objectives for the actual app.
-5. Stable-release support commitments before packaging/public reuse claims.
-   Private security reporting and the current support baseline are documented in
-   SECURITY.md.
-
-License selection is resolved: URLCode is released under the Apache License 2.0,
-`package.json` declares it, and the repository carries the full license text.
-The remaining gates above are engineering and operational, not legal.
-
-The unreleased next-phase source now includes strict bulk/provider interchange,
-local recipes, TypeScript authoring, bounded self-hosted proxy/signals and read-only
-MCP. Local AWS/Vercel/Cloudflare adapter tests and deployment probe tooling exist,
-but actual provider deployments remain unverified. Node process/container hosting
-remains the reference execution target. Guest networking, durable signals and
-realtime capabilities are not provided. See [implementation status](archive/2026-09-19/NEXT-PHASE-PLAN.md)
-and [roadmap](../ROADMAP.md); these additions do not close the operational gates above.
-
-The [internal security audit](SECURITY-AUDIT.md) records reproduced findings, fixes
-and prioritized gaps. Its regressions supplement these gates; they do not replace
-independent assessment or real deployment exercises.
-
-## Hardening follow-up
-
-Implemented: bounded YAML workers and aggregate source budgets, cooperative route
-compilation deadline, scoped/expiring/revocable operator credentials for host
-bindings, executable local/CI operational drills, and a main-only candidate
-signing/SBOM workflow. The loopback-only management API and its atomic SQLite
-mutation audits were part of the `link`/`dynamicLinks` store that PR #126
-removed from core; that functionality moved to the `urlcode-dynamic-link`
-extension (docs/EXTENSIONS.md), which was retired and unpublished on
-2026-09-19. No supported stored-link package ships today, and this runtime does
-not provide one: a project needing a durable link store owns it itself.
-
-Still required: [independent review](SANDBOX-REVIEW.md), [actual deployment proof](OPERATIONAL-PROOF.md),
-and publication/support arrangements. The Apache-2.0 license and the 0.3.0 self-hosted
-release do not close the security and deployment gates. See [release process](RELEASE-SECURITY.md).