@jimhoyd/urlcode 0.4.0-alpha.2 → 0.4.0-alpha.3

package/docs/READINESS.md

@@ -17,14 +17,18 @@ 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) |
@@ -53,8 +41,9 @@ boundary and the license. Use documentation pinned to your runtime revision;
 |---|---|
 | 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) |
+| 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,11 +59,6 @@ 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) |
 | Verify a running deployment matches the project | [Deployment checks](DEPLOYMENT-CHECKS.md) |
 | Inspect target support | [Capabilities and normalized representation](CAPABILITIES.md) |
@@ -83,29 +67,22 @@ 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),
+  [Lambda compilation](SPIKE-LAMBDA-COMPILE.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-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

package/docs/RELEASE-SECURITY.md

@@ -1,181 +1,81 @@
-# Candidate and release security process
+# Candidate and release security
 
-URLCode 0.3.0 is the Apache-2.0 self-hosted baseline; licensing is defined
-in [LICENSE](../LICENSE). Two workflows share one audited build path and differ
-only in what they do with its output:
+The [development pipeline](DEVELOPMENT-PIPELINE.md) is the operational runbook
+for CI selection, release planning, tags, publication and recovery. The
+[September 19 audit](CI-RELEASE-AUDIT-2026-09-19.md) explains the changes;
+[the prior process and failure history](archive/2026-09-19/RELEASE-SECURITY.md)
+is retained as a historical record, not current instructions.
 
-- `candidate.yml` is dispatched manually on main and retains a **signed build
-  candidate** for 30 days without publishing it. Use it to review a commit
-  before tagging it.
-- `release.yml` runs on a `v*` tag whose commit is already on main, and publishes
-  a GitHub release. Publication to npm and GHCR is opt-in per repository variable
-  (`PUBLISH_NPM`, `PUBLISH_CONTAINER`), so a release can be artifacts-only.
+The license remains Apache-2.0. A successful release is not an independent
+security assessment, hostile multi-tenant readiness claim or deployment proof.
+See [release readiness](RELEASE-READINESS.md) and [security](../SECURITY.md).
 
-Neither workflow is a statement that a release is production-ready; see
-[release readiness](RELEASE-READINESS.md).
+## Source and validation
 
-## Publishing an alpha
+A release must name the checked-out commit, already on main, with successful
+full verification of that exact SHA and CodeQL analysis. Full verification
+means a successful nightly or manual `ci.yml` run across every supported OS/Node
+combination; the compact push/PR matrix alone does not authorize publication. Package manifests,
+lockfile versions and tag names must agree. Published peer floors must exist and
+extension tests must resolve the published packages, not workspace source.
+The manual core candidate and tagged core release use the same preparation
+script with the digest-pinned Node image from Dockerfile. Locked dependencies,
+verification, runtime audit, package installation tests and local drills precede
+packing. Build commands in that container receive no GitHub token.
 
-An alpha such as `0.4.0-alpha.1` follows the same path: tag `v0.4.0-alpha.1`
-on a commit that is already on main. The release workflow publishes to npm
-only when the repository variable `PUBLISH_NPM` is `true` and the npm trusted
-publisher for this repository and `release.yml` exists; otherwise the run is
-artifacts-only (a GitHub release with the signed tarball). Publish order is
-core → ui → auth → admin, because the extension packages declare
-`@jimhoyd/urlcode >=0.4.0-alpha.1 <0.5.0` and must resolve the core alpha.
+The candidate workflow stores artifacts without publishing. A tagged release
+publishes npm only when `PUBLISH_NPM=true` and core images only when
+`PUBLISH_CONTAINER=true`. Preparation retains original artifacts for 90 days
+before publication so reruns of the same run reuse them. Manual candidates retain
+their existing 30-day retention. Keep independent last-good artifacts and
+rehearse deployment rollback; Actions retention is not an archival guarantee.
 
-1. Report vulnerabilities privately through [GitHub advisories](https://github.com/jimhoyd-com/urlcode/security/advisories/new).
-   The maintainer triages impact, confirms affected exact revisions, coordinates a
-   fix/retest privately, and publishes an advisory with upgrade guidance when safe.
-   Current reviewed main is the security support baseline; no guaranteed SLA/backports.
-2. Change dependencies through protected PRs. Review upstream provenance/advisories,
-   lockfile integrity and tests. Direct dependencies are exact, npm installs use
-   `npm ci`, CI actions use full commit SHAs, and container bases use SHA-256 digests.
-   Dependabot proposes updates; it does not authorize merging. Never silently
-   refresh dependencies during a candidate build.
-3. After protected main checks pass, a maintainer manually dispatches
-   `.github/workflows/candidate.yml` **on main**, or pushes a `v<version>` tag to
-   run `.github/workflows/release.yml`. The release workflow refuses a tag whose
-   commit is not an ancestor of main, refuses a tag that disagrees with
-   `package.json`, and refuses to build a private or unlicensed package. It reads and validates the digest-pinned Node image directly from Dockerfile,
-   installs without lifecycle scripts, verifies, package-tests and runs local drills.
-   It packs the runtime and creates a CycloneDX dependency SBOM plus a manifest
-   recording source commit, lockfile hash, engine versions and artifact hashes.
-   The package contains `dist/`, produced inside that build from the tagged
-   TypeScript sources by Node's type stripping (`scripts/build.ts`); `dist` is
-   never committed. The manifest records the Node version that stripped it, the
-   locked TypeScript version and a SHA-256 per emitted file
-   (`dist/BUILD-MANIFEST.json`), so a download can be verified by running
-   `npm run build` on the tagged commit with that Node version and comparing its
-   `dist/` file by file. The build strips types and rewrites specifier
-   extensions; it never bundles, minifies or transforms syntax, so every line of
-   `dist/x.js` is the corresponding line of `src/x.ts`. CI's `build-fidelity`
-   job builds twice and diffs the trees, so the transform is known to be
-   deterministic before a tag is cut.
-4. The pinned official `actions/attest` action signs provenance for the package,
-   SBOM and manifest using short-lived GitHub OIDC/Sigstore credentials. No long-lived
-   signing key is stored. Signing permissions exist only in this manual job; build
-   commands run in a container without passing GitHub tokens. Candidate files are
-   retained as GitHub Actions artifacts for 30 days. A release additionally attaches
-   them to the GitHub release, and publishes to npm and to GHCR when those
-   repository variables are enabled.
+## Identity and provenance
 
-   **npm publication holds no credential.** The registry is configured with a
-   trusted publisher naming this repository and `release.yml`, so the publish
-   step exchanges the job's OIDC identity for a credential that lives for the
-   length of one publish. There is no npm token in the repository's secrets to
-   leak, revoke or rotate, and a fork or another workflow cannot publish under
-   this package's name. Provenance is generated on that same identity, so
-   `--provenance` is not passed and its absence is not a downgrade.
+The four per-package workflow filenames are stable npm trusted-publisher
+identities. npm publishing uses OIDC, npm 11.5.1 and a supported Node version,
+with no long-lived npm token. Renaming a workflow or changing the repository
+requires a reviewed registry trust migration. Successful preparation does not
+prove the registry-side identity permits direct publication.
 
-   A bearer token would silently take precedence over this exchange, so the
-   publish step must reference none; `test/release.test.ts` fails if one
-   reappears in it, and checks the npm and Node floors below which the exchange
-   is not attempted at all.
-5. Download the candidate for the intended commit and verify **each file**, e.g.
-   `gh attestation verify jimhoyd-urlcode-0.3.0.tgz --repo jimhoyd-com/urlcode --signer-workflow jimhoyd-com/urlcode/.github/workflows/candidate.yml --source-ref refs/heads/main --source-digest APPROVED_COMMIT_SHA`
-   (use `release.yml` as the signer workflow for a tagged release).
-   Check the verified provenance's source commit against the approved commit, and
-   compare package/SBOM hashes with the signed manifest. A signature establishes
-   provenance, not safety, reproducible bytes or production approval. See
-   [GitHub verification](https://cli.github.com/manual/gh_attestation_verify) and
-   [the official attestation action](https://github.com/actions/attest).
-6. Before registry publication, assign patch/release ownership and retention, and
-   document version/support policy. Before claiming hostile multi-tenant or
-   deployment-specific readiness, close independent-review and deployment gates. Keep last-good verified artifacts and compatible policies;
-   rehearse rollback. Never overwrite a published artifact/version or downgrade a
-   management writer past its audit/security baseline.
+`actions/attest` signs the candidate files with GitHub OIDC/Sigstore provenance.
+Core includes its package archive, dependency SBOM, build manifest, checksums,
+and, for a release, Homebrew formula. Extensions include their archive and
+checksums. The core manifest records source SHA, lockfile hash, Node and
+TypeScript versions and emitted-file hashes. `dist/` is built, never committed.
 
-The SBOM describes npm dependencies; it is not a complete OS/container SBOM. Hosted
-runners and action runtimes remain platform-controlled. Digest pins improve supply
-chain integrity but do not prove byte-for-byte reproducibility or engine safety.
-Signing verification must be demonstrated on a successful main workflow run before
-claiming a candidate has been signed. Workflow definition alone is not that evidence.
-`release.yml` ran successfully for the first time publishing `v0.4.0-alpha.1`
-(2026-09-18), after the fixes below; treat any repository whose workflow has not
-had a real successful tagged run the same way this one was treated before that.
+Verify an artifact with `gh attestation verify <tarball> --repo
+jimhoyd-com/urlcode`, and constrain verification to the expected workflow,
+source ref and source digest for the selected release. Compare the source and
+artifact hashes to the intended release, rather than accepting any signed file.
+A signature establishes provenance, not safety or reproducibility. The npm SBOM
+is not a complete OS/container SBOM; hosted runners remain platform-controlled.
 
-## What broke on every first release, and why
+## Immutability and channels
 
-Four repositories (core, ui, auth, admin) each cut their first tagged release in
-the same session. Every one hit a subset of the same bugs, because each
-`release.yml` was written and reviewed but never actually run end-to-end against
-a real tag before. None of this is repository-specific; check for all of it
-before trusting an unexercised release workflow:
+Never delete/recreate or move a version tag to repair a workflow. A source fix
+requires a new version. Repeating publication of an existing npm version requires
+identical SHA-512 integrity. GitHub assets are compared and missing assets added;
+existing unequal assets are never clobbered. Transient registry errors fail
+closed rather than count as an unpublished version.
 
-- **`npm ci` on the bare runner's root-owned npm.** A build that runs entirely
-  inside a pinned Docker image never calls `actions/setup-node`, so a later
-  `npm install --global npm@11.5.1` (needed for the trusted-publishing floor)
-  hits the runner's preinstalled, root-owned npm and fails `EACCES`. Add
-  `actions/setup-node` before any step that installs global npm packages, even
-  if the main build never touches the runner's own Node.
-- **The floor check must run after the pin, not before.** A guard asserting
-  "npm ≥ 11.5.1" is useless directly after `setup-node` with `node-version: '22'`,
-  which bundles npm ~10.9.x — it can never pass. The floor only means something
-  once the publish step's own `npm install --global npm@11.5.1` has actually run.
-- **`npm publish` refuses an unqualified prerelease.** `You must specify a tag
-  using --tag when publishing a prerelease version.` npm's safety default is
-  `latest`; a prerelease must derive an explicit dist-tag from its version
-  (`0.1.0-alpha.1` → `alpha`, anything without a `-` → `latest`) and pass
-  `--tag`. This path is only exercised by a package's *first* prerelease, so it
-  silently sat broken in every repository until each hit it for the first time.
-- **`npm pack --pack-destination candidate` needs `candidate/` to exist first.**
-  npm does not create the destination directory; `mkdir -p candidate` first.
-- **A private repository's unauthenticated `git fetch origin main` cannot work.**
-  If checkout uses `persist-credentials: false` (correct, for a step that
-  should not need write access) and the repo is private, `git fetch` fails
-  `could not read Username for 'https://github.com'` before ever reaching the
-  version check. Compare the tag against main through the GitHub API instead
-  (`gh api repos/OWNER/REPO/compare/main...SHA --jq .status`, expecting
-  `identical` or `behind`) — it needs no credentials and stays read-only. Public
-  repositories can keep the plain fetch; it works there.
-- **`--conditions=development` in `npm run verify`'s test script resolves peers
-  to source that a real npm install never ships.** The regular CI job symlinks
-  sibling checkouts in place of `node_modules`, so `./src/*.ts` exists and the
-  flag is correct there. A release installs real published tarballs of its
-  peers, which only ever ship `dist/`, so the same flag makes every import of a
-  peer fail `ERR_MODULE_NOT_FOUND`. Drop the flag for the release-workflow test
-  invocation specifically (run `node scripts/check-sqlite.mjs` explicitly first,
-  since bypassing `npm test` skips that pretest hook), and audit any test file
-  that separately hardcodes the flag in a spawned child process — it has to be
-  fixed the same way, independently, wherever it appears.
-- **A peer-install command with the wrong flag combination is a silent no-op.**
-  `npm install --no-save --no-package-lock --ignore-scripts --legacy-peer-deps
-  <peer>@<version>` installed *nothing*, with no error, when the target package
-  names already appear in `peerDependencies` — `npm ci` earlier reports "added N
-  packages" as if it worked. Confirm the install actually happened
-  (`ls node_modules/@scope/*/package.json` and print each version) rather than
-  trusting the exit code; `--no-save --ignore-scripts <specs>` (no
-  `--no-package-lock`, no `--legacy-peer-deps`) is the version that works, paired
-  with `git diff --exit-code -- package.json package-lock.json` to prove nothing
-  was recorded as a dependency.
-- **A version published from an unbuilt checkout is burned forever.** npm never
-  allows a version to be replaced. `@jimhoyd/urlcode-auth@0.1.0-alpha.1` reached
-  the registry from something other than the CI workflow (a manual `npm
-  publish` run before `npm run build` had produced `dist/`), so the published
-  tarball contained only metadata files and no code. Every consumer's typecheck
-  failed with `Cannot find module '@jimhoyd/urlcode-auth'` — a real, correct
-  failure, not a bug in the consumer. The only fix is bumping to a new version
-  and publishing that instead; nothing can repair or unpublish the bad one.
-  **Never run `npm publish` by hand outside the release workflow** — the
-  workflow is the only place that reliably builds before packing.
-- **`ENEEDAUTH` on `npm publish` under trusted publishing usually means the
-  registry-side configuration doesn't exist or doesn't permit direct publish
-  yet**, not a workflow bug. Trusted publishing needs an entry under the
-  package's npm settings ("Trusted Publisher") naming the exact GitHub
-  org/repo and workflow filename, with no environment set unless the workflow
-  declares one; recent npm UI changes default new configurations to
-  "stage publish" only; "allow npm publish" (direct publish, which is what
-  this project's workflows do) must be explicitly enabled too. A wrong
-  org/repo/workflow match tends to surface as a 404, not `ENEEDAUTH`;
-  `ENEEDAUTH` is the signature of no matching configuration existing at all.
-- **Publish order matters and is easy to get backwards.** Extension packages
-  declare `@jimhoyd/urlcode >=X <Y` as a peer range; publish core before ui,
-  auth or admin, or their own release-workflow peer-install step has nothing
-  real to resolve against.
+Alpha versions use npm/GHCR `alpha` and GitHub prerelease classification. New
+GitHub releases are not automatically promoted to GitHub `latest`. Mutable npm
+and container channels cannot regress to an older version. Existing core image
+versions are reused only with matching source labels; unlabeled historical
+images require a reviewed migration rather than an inferred identity.
 
-None of the above is exotic; all nine bugs were found by actually running each
-workflow against a real tag, one release at a time, and reading the actual
-failure rather than guessing from the workflow source. Treat "the workflow file
-looks right" and "the workflow has actually published successfully once" as two
-different, unrelated claims.
+The coordinator creates one package tag at a time and waits for success before
+releasing dependents. Shared publication concurrency avoids cross-version races.
+The active immutable-tag rule blocks release tag updates/deletions with no
+bypass actors; its configuration is in `.github/rulesets/release-tags.json`. No automation needs permission to bypass main checks or approve
+its own PR. A repository-scoped GitHub App is the preferred eventual automation
+identity; a narrowly scoped fine-grained PAT can support a maintainer script.
+
+## Remaining validation
+
+Keep full supported-OS/Node coverage and archive-install tests green. The actual
+publish path, OIDC trust for every package, tag protection, GHCR behavior and
+partial-failure recovery must be verified on an authorized release; local tests
+and workflow inspection cannot prove them. The release helpers do not alter
+historical npm channels, GitHub flags, tags or registry artifacts.

package/docs/RESILIENCE.md

@@ -156,6 +156,6 @@ admission/fairness, production metrics/exporters, dedicated slow-reader protecti
 provider-level mitigation validation and sustained failure/soak testing. These are
 free-runtime/operator requirements.
 
-Core has no durable store of its own to recover; a future durable-state
-extension (such as the planned `urlcode-dynamic-link`) is responsible for its
-own management listener, backup and recovery procedure once it exists.
+Core has no durable store of its own to recover; a durable-state extension is
+responsible for its own management listener, backup and recovery procedure. No
+such extension ships today — `urlcode-dynamic-link` has been retired.

package/docs/ROUTING.md

@@ -84,10 +84,9 @@ any per-visitor session record. Git owns route behavior and code; user-created r
 their own persistence, backup and export lifecycle.
 
 Core has no native handler for this today: the `link` handler that implemented
-it was removed. Stored short links are moving to a future
-`urlcode-dynamic-link` extension package (mount-based, like `auth`/`admin`,
-not yet published); a project needing them declares an `extension` mount once
-that package exists.
+it was removed. The `urlcode-dynamic-link` extension package that replaced it
+has been retired and unpublished, so a project needing stored short links owns
+that storage itself.
 
 Functions still cannot access databases, the filesystem or network directly.
 General application state and realtime sessions remain future work.

package/docs/SECURITY-AUDIT.md

@@ -85,7 +85,7 @@ Management event status 0 means no response headers were sent before disconnect.
 An aborted request may have committed a mutation: reconcile record/version before
 retrying. These logs are best effort, may be dropped under pressure, identify a configured credential ID (or a legacy shared token), and are not a
 tamper-evident journal. Successful store mutations now have separate transactional
-audit records; see [management security](MANAGEMENT-SECURITY.md). A failed sink needs collector/operator recovery;
+audit records; see [management security](archive/2026-09-19/MANAGEMENT-SECURITY.md). A failed sink needs collector/operator recovery;
 URLCode cannot report failures reliably through the same broken output stream.
 
 ## Boundaries checked
@@ -122,7 +122,7 @@ limits. No anonymous code/config upload service is approved by these changes.
 collection/action scopes, expiry and hot revocation, plus atomic SQLite mutation
 audits are implemented. Legacy shared tokens remain for compatibility. There is
 no public user-account system, MFA/SSO, built-in rate limiter, credential issuance
-service or external tamper-evident archive. See [management security](MANAGEMENT-SECURITY.md).
+service or external tamper-evident archive. See [management security](archive/2026-09-19/MANAGEMENT-SECURITY.md).
 
 **Before claiming operational readiness:** execute sustained mixed-workload soak,
 backup restoration, disk-full, process-kill, proxy timeout and rollback drills on

package/docs/SPECIFICATION.md

@@ -158,10 +158,10 @@ keys preserve repeated values. Headers are forwarded only through explicit maps.
 ## Stored links
 
 Core has no native `link` handler or `dynamicLinks` project flag; both were
-removed. Stored short links are moving to a future `urlcode-dynamic-link`
-extension package (mount-based, like `auth`/`admin`), not yet published. A
-project needing them declares an `extension` mount once that package exists;
-there is no in-core replacement or deprecation shim for `link`/`dynamicLinks`.
+removed. The `urlcode-dynamic-link` extension package that replaced them has
+been retired and unpublished, so a project needing stored short links owns that
+storage itself; there is no in-core replacement or deprecation shim for
+`link`/`dynamicLinks`.
 
 ## Functions
 
@@ -329,7 +329,9 @@ are local Git-owned examples; they grant no capabilities. [Build-time TypeScript
 is separate from runtime execution.
 
 The [tooling SDK and optional local MCP](TOOLING.md) inspect and validate without
-executing handlers or reading binding values. [Provider conformance](PROVIDER-VERIFICATION.md)
+executing handlers or reading binding values. MCP defaults to inspection; the
+explicit `--allow-authoring` option enables bounded project writes, separately
+from host-file loading and grants. [Provider conformance](PROVIDER-VERIFICATION.md)
 distinguishes local adapter replay from actual deployment observations; no real
 provider deployment is implied by CI. [Proxy and signal egress](EGRESS.md) requires
 external revision-pinned operator grants and bounded host-owned transport;

package/docs/SPIKE-AI-FRAMEWORK-BENCHMARK.md

@@ -32,7 +32,7 @@ Before building the application or a new harness, investigate:
 - Agent productivity studies, framework comparison applications and standard
   CRUD/full-stack benchmark applications.
 - URLCode's existing [agent harness](../benchmarks/agent/README.md), authoring
-  evals, [next-steps plan](NEXT-STEPS.md), and runtime benchmarks in
+  evals, [next-steps plan](archive/2026-09-19/NEXT-STEPS.md), and runtime benchmarks in
   `benchmarks/routing.ts`, `benchmarks/bulk.ts` and
   `benchmarks/sandbox-vs-trusted.ts`.
 
@@ -198,8 +198,9 @@ For each verified, actionable issue include:
 - Acceptance criteria and related/duplicate issue links.
 
 Use the owning repository's issue template and the ownership map in
-[AGENTS.md](../AGENTS.md): core/runtime issues belong here, public documentation
-in `urlcode-docs`, and extension defects in the corresponding extension repository.
+[AGENTS.md](../AGENTS.md): core/runtime issues belong here, documentation
+included -- `urlcode-docs` is deleted and cannot accept issues -- and extension
+defects in the corresponding extension repository.
 Update existing issues with new evidence rather than duplicating them. Track
 prepared, filed, duplicate and unverified dispositions in the findings report;
 file verified issues and retain unresolved hypotheses as explicitly unverified
@@ -220,8 +221,8 @@ current contract when documents and historical benchmark assumptions differ.
 
 Preserve Agent A's baseline before editing guidance. Then propose the smallest
 authoritative set of changes that makes the principle clear to people and agents,
-including when custom JavaScript is appropriate. Public authoring guidance belongs
-in `urlcode-docs`; contributor records and spikes remain here. Do not copy the rule
+including when custom JavaScript is appropriate. Public authoring guidance and
+contributor records both belong here, now that `urlcode-docs` is deleted. Do not copy the rule
 everywhere or expose the experimental prompt as product guidance by accident.
 
 ## Phase 6 — Fastify comparison

package/docs/SPIKE-BUSINESS-SUITE.md

@@ -1,17 +1,25 @@
 # URLCode business suite spike
 
+> Review update, 2026-09-19: Current status: an unapproved candidate list, gated on observed repetition
+> and benchmark evidence under PROJECT-DIRECTION.md. The short-link products
+> are retired; the seven-product recommendation below is historical, not agreed
+> current scope. No business-suite implementation is implied.
+
+
 Date: 2026-09-18. Status: proposal, not an implemented contract or production claim.
 Core inspected at `50790d3` (0.4.0-alpha.1), plus local auth, admin, UI and
 shortener source/status files. Competitor research below is a documentation
 review, not hands-on benchmarking. Features and commercial packaging can change.
 
 > **Update:** this proposal was written when `link`/`LinkStore` was still a
-> native core feature. Core no longer has that API — it was extracted to the
-> separate [`urlcode-dynamic-link`](https://github.com/jimhoyd-com/urlcode-dynamic-link)
-> package. References below to core owning link storage (e.g. "Reuse core's
-> LinkStore", "Retain core link semantics", the `core LinkStore -> short`
-> dependency line) describe the pre-extraction state this spike was proposing
-> against, not current core.
+> native core feature. Core no longer has that API — it was extracted to a
+> separate `urlcode-dynamic-link` package, which has since been retired,
+> unpublished and deleted (September 2026), along with the `urlcode-short`
+> shortener this document proposes. Those two products are no longer planned.
+> References below to core owning link storage (e.g. "Reuse core's LinkStore",
+> "Retain core link semantics", the `core LinkStore -> short` dependency line)
+> describe the pre-extraction state this spike was proposing against, and the
+> `urlcode-short` migration sections record an abandoned plan.
 
 ## Recommendation