@jimhoyd/urlcode 0.4.0-alpha.2 → 0.4.1

package/docs/PRERENDER.md

@@ -2,8 +2,10 @@
 
 Render a project's function and middleware routes once, at build time, into a
 project whose routes are all native `page` handlers. The published site answers
-from prevalidated byte buffers: no guest code runs to serve a request, so the
-sandbox, its deadline and its memory budget are not on the request path at all.
+from prevalidated byte buffers: no guest code runs to serve a request at all,
+so whatever execution mode the source routes used — trusted by default, or
+isolated QuickJS/WASM where a route declares `sandbox: true` — along with its
+deadline and memory budget where sandboxed, is not on the request path.
 
 The shared orchestration ships as a build helper, `@jimhoyd/urlcode/prerender`, and the
 runnable recipe is [`examples/prerender`](../examples/prerender/README.md), which
@@ -24,7 +26,7 @@ and publish the result:
 
 ```
 function + template middleware  ──render once──▶  HTML file  ──▶  page route
-        (sandbox, build time)                                   (no sandbox)
+   (trusted or sandboxed, build time)                        (no guest code)
 ```
 
 The alternative — reading Markdown through `next().text()` on a native route —
@@ -111,9 +113,11 @@ specifically:
   instead of hanging on its worker threads.
 
 The helper is operator build tooling. It runs in Node with normal filesystem
-access because it is not guest code; nothing here gives the sandbox a filesystem,
-and no host-code fallback is introduced. It is a separate package export from the
-runtime for that reason. Review it as you review any deployment tooling.
+access because it is not guest code; it does not itself widen a source route's
+declared execution mode — a route with `sandbox: true` still renders isolated,
+with no filesystem, and no host-code fallback is introduced for it. It is a
+separate package export from the runtime for that reason. Review it as you
+review any deployment tooling.
 
 ## Assembling a site
 
@@ -196,8 +200,9 @@ Two consequences worth knowing:
   and their imports exceed the budgets cannot be split, and fails with the
   collector's message. That is a route to make smaller, not a pass to add.
 
-The [urlcode-docs showcase](https://github.com/jimhoyd-com/urlcode-docs) renders
-62 documentation pages this way.
+The `urlcode-docs` site rendered 62 documentation pages this way. That
+repository has since been deleted, so no link is given; the runnable
+version of the same pattern is [`examples/prerender`](../examples/prerender/README.md).
 
 ## Larger sites: generating the source project
 
@@ -219,9 +224,8 @@ things to hold onto:
   interpolates, but content injected as raw HTML is published as written. Whatever
   produces that HTML owns its safety.
 
-The [urlcode-docs showcase](https://github.com/jimhoyd-com/urlcode-docs) builds
-its site this way. That is a working integration, not a deployment or performance
-claim.
+The `urlcode-docs` site built itself this way before that repository was
+retired. It was a working integration, not a deployment or performance claim.
 
 ## What this is not
 
@@ -231,3 +235,11 @@ native bodies readable. Not a template engine — the template is ordinary
 middleware you write. Not a CLI command: prerendering is a step inside a build
 that already runs JavaScript, so the helper is a library. Content compilation,
 sanitization, search, asset assembly and deployment stay in the application.
+
+
+Trusted build-time functions and middleware use ordinary Node imports, including
+npm packages and dynamic imports. The pass planner applies source-graph budgets
+only to `sandbox: true` routes; it does not parse trusted modules as sandbox
+code. Page-count and output-byte budgets still apply to both modes. After
+rendering, emit native page/file routes without middleware, then use the static
+build target. Static hosting cannot execute middleware on incoming requests.

package/docs/PROJECT-DIRECTION.md

@@ -40,8 +40,8 @@ capability grants. Application data stays in the operator's systems.
 
 - **Not a URL shortener.** Core is redirects, validated responses, request
   functions, middleware, pages, static assets and downloads. Stored short
-  links are moving to a future `urlcode-dynamic-link` extension package
-  (mount-based, like `auth`/`admin`, not yet published), not a core handler.
+  links are not a core handler; the `urlcode-dynamic-link` extension package
+  that owned them has been retired and unpublished.
 - **Not a general Node web framework.** There is no framework code to write
   for routing, validation, middleware wiring or policies — those are declared
   in YAML and enforced by the runtime. Function/middleware code that needs
@@ -104,7 +104,7 @@ lines an agent generated, how many are the idea and how many are plumbing. A
 traditional build might be 2,900 lines of business logic inside 18,400; the
 same application on URLCode should be the same 2,900 inside a few thousand.
 Until a reproducible benchmark shows that ratio, the thesis is a hypothesis,
-and [next steps](NEXT-STEPS.md) puts the benchmark before the features.
+and [the roadmap](../ROADMAP.md) puts the benchmark before the features.
 
 ## License
 

package/docs/READINESS.md

@@ -10,21 +10,26 @@ 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 isolated runtime and use
-local environment loading like `test`. Pass an external `--policy` for explicitly
-authorized bindings. No destination redirects are followed, credentials are not
+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
+`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,
-middleware count, policies, generated marker and the policy description). It
+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.

package/docs/README.md

@@ -1,15 +1,5 @@
 # URLCode documentation
 
-> **Public documentation is authored in a separate `urlcode-docs` repository,
-> not generated from this tree.** New reader-facing pages belong there; `docs/`
-> here keeps contributor and maintainer material (local development, CI, release
-> process, reviews, spikes, plans and the generated field reference). The
-> reader-facing pages still listed below are being migrated.
->
-> `urlcode-docs` is currently private, so it isn't publicly browsable yet —
-> until it is, this file and this repository's README are the practical
-> reference.
-
 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
@@ -26,8 +16,6 @@ boundary and the license. Use documentation pinned to your runtime revision;
 | 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) |
-| Explore a standalone application | [URLCode Short demo](https://github.com/jimhoyd-com/urlcode-short), [build retrospective](https://github.com/jimhoyd-com/urlcode-short/blob/main/docs/BUILD-RETROSPECTIVE.md) |
-| Explore a static docs-site integration | URLCode Docs project (private repository; not yet publicly browsable) |
 | 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) |
@@ -51,10 +39,11 @@ boundary and the license. Use documentation pinned to your runtime revision;
 
 | Goal | Start here |
 |---|---|
-| Add accounts, sign-in and protected routes | [urlcode-auth](https://github.com/jimhoyd-com/urlcode-auth#readme) |
-| Manage users, sessions, roles and audit | [urlcode-admin](https://github.com/jimhoyd-com/urlcode-admin#readme) |
-| Restyle every extension page and translate copy | [urlcode-ui](https://github.com/jimhoyd-com/urlcode-ui#readme), [ui contract](https://github.com/jimhoyd-com/urlcode-ui/blob/main/CONTRACT.md) |
+| 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) |
@@ -70,12 +59,7 @@ boundary and the license. Use documentation pinned to your runtime revision;
 | 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 the design behind policies, plugins and templates | [Extensions spike](SPIKE-EXTENSIONS.md) |
-| Read the design for an authentication and authorization plugin | [Auth spike](SPIKE-AUTH.md) |
-| Read the design for the administration extension that manages users | [Admin spike](SPIKE-ADMIN.md) |
-| Read the design for the shared template kit every extension renders with | [UI kit spike](SPIKE-UI.md) |
-| Read the review of the extension model, its precedents and alignment | [Extension model review](SPIKE-EXTENSION-MODEL.md) |
-| Read the design for compiling function routes into per-route Lambdas | [Lambda compile spike](SPIKE-LAMBDA-COMPILE.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) |
@@ -83,29 +67,21 @@ boundary and the license. Use documentation pinned to your runtime revision;
 | 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) |
 
-## Evidence, reviews and design records
+## Direction and evidence
 
-These are dated records, not guides. They say what has been checked and what
-has not, and why the design is the way it is.
+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).
 
-| Record | What it is |
-|---|---|
-| [Release readiness](RELEASE-READINESS.md) | Verified safeguards, open gates, supported scope |
-| [Usability review](USABILITY-REVIEW.md) | Where the framework is easier or harder than the tools it replaces, and ranked changes |
-| [Next steps](NEXT-STEPS.md) | The phased plan: agent discovery, context compression, retrieval, the ladder, benchmarks and the remaining proof gaps |
-| [AI-first framework benchmark spike](SPIKE-AI-FRAMEWORK-BENCHMARK.md) | Proposed research-first, independent-agent application and runtime benchmark with a verified issue/improvement loop |
-| [Next-phase implementation status](NEXT-PHASE-PLAN.md) | Source additions after 0.3.0 shipped in 0.4.0-alpha.1, and their evidence limits |
-| [Security review](SECURITY-AUDIT.md) | Internal findings and fixes; not an independent test |
-| [Standards audit](STANDARDS.md) | How the runtime conforms to the RFCs it touches |
-| [Sandbox review package](SANDBOX-REVIEW.md) | What an independent reviewer needs; assessment not yet performed |
-| [Operational drills](OPERATIONAL-PROOF.md) | Deployment acceptance drills CI runs |
-| [Release security](RELEASE-SECURITY.md) | Candidate signing and publication process |
-| [Core version alignment](VERSION-ALIGNMENT.md) | The supported core floor for each downstream repository, how it is declared, and the publish-then-raise-then-regenerate order |
-| [Extension model review](SPIKE-EXTENSION-MODEL.md) | Why extensions are shaped this way, with framework precedents |
-| [Extensions spike](SPIKE-EXTENSIONS.md) | The design behind policies and plugins; implemented |
-| [Lambda compile spike](SPIKE-LAMBDA-COMPILE.md) | Proposal: per-route Lambdas for functions; not implemented |
-| Auth, admin and UI spikes | Live in their repositories: [auth](https://github.com/jimhoyd-com/urlcode-auth/blob/main/docs/SPIKE-AUTH.md), [admin](https://github.com/jimhoyd-com/urlcode-admin/blob/main/docs/SPIKE-ADMIN.md), [ui](https://github.com/jimhoyd-com/urlcode-ui/blob/main/docs/SPIKE-UI.md) |
-| [Roadmap](../ROADMAP.md) | Implemented versus planned |
+- [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 the runnable cookbook and fixtures.
-Infrastructure limits are deployment settings, not fields to invent in route YAML.
+Examples are educational unless backed by runnable fixtures. Infrastructure
+limits are deployment settings, not fields to invent in route YAML.

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

@@ -0,0 +1,50 @@
+# 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

@@ -0,0 +1,73 @@
+# 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

@@ -41,7 +41,7 @@ deferred to the post-merge run.
 | 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`, `@jimhoyd/urlcode-middleware@0.1.0-alpha.1`. Observed in passing: auth's dist-tags are split — `alpha` points at `0.1.0-alpha.2` while `latest` still points at `0.1.0-alpha.1`, so a plain `npm install @jimhoyd/urlcode-auth` resolves the older alpha. 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. |
+| 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
@@ -93,7 +93,7 @@ local recipes, TypeScript authoring, bounded self-hosted proxy/signals and read-
 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](NEXT-PHASE-PLAN.md)
+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
@@ -107,10 +107,10 @@ 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, and its hardening, now belongs to the
-`urlcode-dynamic-link` extension (docs/EXTENSIONS.md), published on npm as
-`@jimhoyd/urlcode-dynamic-link@0.1.0-alpha.1` as of 2026-09-19, not this
-runtime.
+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