@jimhoyd/urlcode 0.4.2 → 0.4.6

package/docs/READINESS.md

@@ -1,153 +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.
-When `ready` is false, `notReadyReasons` lists each failed condition:
-`no-active-routes`, `route-count-mismatch`, `failed-checks` and
-`uncovered-route-methods` (see `uncovered` for the pairs). `unassertedCases` never
-affects `ready`. 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,93 +0,0 @@
-# URLCode documentation
-
-Choose a starting point, then use the topic directory below when you need detail.
-Use documentation from the same pinned revision as your runtime.
-
-| I want to… | Start here |
-|---|---|
-| Understand what URLCode does | [Framework](FRAMEWORK.md) |
-| Build my first project | [Installation](INSTALL.md), then [YAML guide](YAML-GUIDE.md) |
-| Build a site with UI, accounts and admin | [Composing a site](COMPOSING-A-SITE.md) |
-| Have an AI author a project | [AI authoring](AI-AUTHORING.md), [agent index](../llms.txt) |
-| Deploy and operate a project | [Operations](OPERATIONS.md) |
-| Contribute to URLCode | [Contributing](../CONTRIBUTING.md), [local development](LOCAL-DEVELOPMENT.md) |
-
-The [specification](SPECIFICATION.md) owns implemented semantics; the
-[generated field reference](YAML-REFERENCE.md) lists accepted fields.
-[Project direction](PROJECT-DIRECTION.md) explains the product boundary.
-
-## 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) |
-| 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) |
-| Understand exact behavior | [Specification](SPECIFICATION.md), [routing](ROUTING.md), [HTTP](HTTP.md) |
-| Run examples | [Executable 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) |
-| 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) |
-| 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-0.4.2.md

@@ -1,30 +0,0 @@
-# URLCode 0.4.2
-
-Core, UI, auth and admin share this explicitly selected stable version. Independent package versioning remains enabled.
-
-```sh
-npm install --save-exact @jimhoyd/urlcode@0.4.2 @jimhoyd/urlcode-ui@0.4.2 @jimhoyd/urlcode-auth@0.4.2 @jimhoyd/urlcode-admin@0.4.2
-```
-
-### admin-copy-project-override.md
-
-Project translations of `adminUi.*` ids in `ui/copy/<locale>.json` now reach the admin console.
-
-In a composed site the console copy source is built with `createAdminPresentation({ base: kit.presentation })`, and the admin ids were resolved only from the bundled English, so a project's `adminUi.*` entries were silently ignored. When a base presentation is given, an admin id the base resolves for the request's locale now wins; otherwise the bundled admin English still answers. Hosts that pass no `base` and hosts that supply their own presentation are unchanged.
-
-### ui-styles-once-per-verify.md
-
-Compile Tailwind once per `npm run verify`.
-
-No API change and no change to the generated stylesheet. `verify` used to run
-`typecheck` then `build`, and each of those runs `styles`, so
-`scripts/build-styles.mjs` compiled the same minified CSS twice per
-verification. `verify` now runs `styles` once and then the compiler-only
-`typecheck:tsc` and `build:tsc` scripts. `typecheck` and `build` are unchanged
-from a caller's point of view: each still runs `styles` first, so either one
-works on its own from a fresh checkout.
-
-Nothing is cached and nothing is skipped because an output already exists; the
-single run is unconditional, so a source change is still picked up.
-
-Publish to the npm `latest` channel only after exact-commit CI and candidate verification. Existing tags and the `alpha` channel stay unchanged. Update the standalone starter after core registry installability is verified. This preparation is not evidence of publication or an independent security assessment.