@jimhoyd/urlcode 0.4.0-alpha.2 → 0.4.1

package/docs/RELEASE-SECURITY.md

@@ -1,181 +1,96 @@
-# Candidate and release security process
-
-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:
-
-- `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.
-
-Neither workflow is a statement that a release is production-ready; see
-[release readiness](RELEASE-READINESS.md).
-
-## Publishing an alpha
-
-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.
-
-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.
-
-   **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.
-
-   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.
-
-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.
-
-## What broke on every first release, and why
-
-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:
-
-- **`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.
-
-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.
+# Candidate and release security
+
+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.
+
+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).
+
+## Source and validation
+
+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 candidate builds all package archives once using the digest-pinned Node
+image from Dockerfile; publishers promote those exact signed bytes. The builder
+installs Git from Debian for repository-fixture tests; Git is a test dependency,
+not an addition to the runtime image or npm package. Locked dependencies,
+verification, runtime audit, package installation tests and local drills precede
+packing. Build commands in that container receive no GitHub token.
+
+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`. Candidate and release artifacts are retained for 90 days, and each package
+GitHub release stores the complete signed candidate bundle. Retries verify and
+reuse original retained or durable bytes; missing originals fail closed. Keep independent last-good artifacts and
+rehearse deployment rollback; Actions retention is not an archival guarantee.
+
+## Identity and provenance
+
+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.
+
+`actions/attest` signs the candidate files with GitHub OIDC/Sigstore provenance.
+The candidate bundle includes all four archives, dependency SBOM, build manifest,
+train metadata, checksums and Homebrew formula. Each publisher retains that
+bundle and publishes only its selected npm archive. New annotated version tags
+pin the candidate run ID and signed-manifest SHA256. The run ID is also bound
+into the manifest; the digest prevents another attempt of that run from
+substituting different artifacts. The core manifest records source SHA, lockfile hash, Node and
+TypeScript versions and emitted-file hashes. `dist/` is built, never committed.
+
+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.
+
+## Immutability and channels
+
+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.
+
+Alpha versions use npm/GHCR `alpha` and GitHub prerelease classification.
+Explicit stable versions use npm `latest` and normal GitHub releases. Only the
+stable core release advances GitHub `latest`, so the core installer cannot pick
+an extension release. Stable preparation removes Changesets prerelease mode;
+existing alpha artifacts, tags and channel pointers remain unchanged. 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.
+
+The coordinator verifies candidate availability and provenance before creating
+any version tag, then creates one at a time and waits for successful publication
+and consumer-facing registry installability 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.
+
+The coordinated `.3` release proved the existing OIDC identities, but exposed
+missing-artifact retry behavior tracked in #223. New workflows fail closed or
+recover verified durable bytes; old immutable tags retain their original
+workflow code. The new promotion path still needs a future explicitly authorized
+release rehearsal; implementing it does not publish a new version.

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
 
@@ -202,7 +202,11 @@ entry may likewise be a string, normalized to `{source: <string>}`. Only the
 long form exists after loading, so `routes`, `audit`, `explain`, revision hashes
 and the field reference describe the expansion.
 
-ES modules only (`.mjs` or `.js`, independent of Node package settings).
+ES modules only. `.mjs` is loaded as ESM in both modes. A `sandbox: true` route
+also reads `.js` as ESM independently of Node package settings, but a trusted
+route imports `.js` through Node's own loader, so an ESM `.js` module needs the
+nearest `package.json` to declare `"type": "module"`; under `"type": "commonjs"`
+it fails activation. Prefer `.mjs` for modules that must work in either mode.
 [Build-time TypeScript authoring](TYPESCRIPT-AUTHORING.md) can produce these
 JavaScript modules in a separate output project; serving does not transpile them.
 The build never imports application code into Node, uses fixed compiler settings,
@@ -329,7 +333,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
 

package/docs/SPIKE-CORE-LAYERING.md

@@ -1,24 +1,41 @@
 # Spike: layering `link` and `middleware` out of core
 
+> Review update, 2026-09-19: Current baseline: **both extractions this spike
+> proposes are over, and neither ended in a shipped separate package.** Link
+> extraction completed and the resulting package was then retired. Middleware
+> extraction never completed: core still implements native middleware, and the
+> separate middleware extension — which added a different API with per-entry
+> sandboxing — has itself been unpublished at `0.1.0-alpha.2` and its
+> repository deleted. The extraction direction below is superseded, and it is
+> not an instruction to remove core middleware: core's native `middleware:`
+> array is now the only implementation of per-route middleware there is.
+>
+> An earlier version of this note said "monorepo work is starting now:
+> middleware moves in as a separate package first, and folds into core
+> afterward." Monorepo work is still starting, for core, auth, admin and UI —
+> but the middleware clause is void. There is no package to move in and
+> nothing to fold in afterward.
+
+
 Status: proposal, nothing implemented. No code in this repository does any of
 this, and nothing here is committed scope. This combines two extraction ideas
 into one spike because they share a mechanism and a sequence, not because
 either is blocked on the other.
 
-> **Update:** this spike's `link` extraction (Phase 1 below) has since been
-> implemented — core no longer has a native `link`/`LinkStore`/`dynamicLinks`
-> API; it now lives in the separate
-> [`urlcode-dynamic-link`](https://github.com/jimhoyd-com/urlcode-dynamic-link)
-> package. Present-tense references to `link` as a core feature elsewhere in
-> this document describe the pre-extraction state this spike was analyzing,
-> not current core.
+> **Update:** this spike's `link` extraction (Phase 1 below) was implemented —
+> core no longer has a native `link`/`LinkStore`/`dynamicLinks` API — and the
+> separate `urlcode-dynamic-link` package that received it has since been
+> retired, unpublished from npm and its repository deleted (September 2026).
+> Nothing owns stored links today. Present-tense references to `link` as a core
+> feature elsewhere in this document describe the pre-extraction state this
+> spike was analyzing, not current core.
 
 ## The shape this is aiming at
 
 Core's job is to stay the smallest thing that is still a complete product on
 its own: YAML routing (`redirect`/`respond`/`page`/`static`/`download`) plus
 `function`, the one primitive with an actual serverless story
-([`SPIKE-LAMBDA-COMPILE.md`](SPIKE-LAMBDA-COMPILE.md) — compile each `function`
+([`SPIKE-LAMBDA-COMPILE.md`](archive/2026-09-19/SPIKE-LAMBDA-COMPILE.md) — compile each `function`
 route to its own Lambda, the pattern `src/build-cloudflare.ts` already uses).
 That base alone serves static and dynamic content and deploys anywhere
 (`docs/FRAMEWORK.md` layer 1–3). Everything past that — accounts, admin,
@@ -41,7 +58,8 @@ honest instead of inventing two different shapes:
 - **Mount ownership** (`route.extension`, `RuntimeExtension.activate` →
   `ExtensionInstance.handle`): an extension owns an exclusive `/prefix/*` and
   answers every request under it. This is the shape `link` needs — it already
-  behaves like a self-contained mount (`docs/DYNAMIC-LINKS.md`), and
+  behaves like a self-contained mount (documented in the since-retired
+  `urlcode-dynamic-link` package), and
   `auth`/`admin` already use it for `/account/*` and `/admin/*`
   (`docs/FRAMEWORK.md:10-15`).
 - **Wrap without owning** (`ExtensionInstance.authorize`, called when a route
@@ -161,7 +179,15 @@ before anything here is treated as settled.
   need to exist or be attached before their Phase 2 work can be written or
   verified, matching the constraint already flagged for `link`.
 
-## Repo governance for the two new repos (decided)
+## Repo governance for the two new repos (decided — both repos since deleted)
+
+> **Historical, 2026-09-19.** Both repositories this section governs were
+> created, released once, and then deleted; both packages are unpublished. The
+> decisions below were applied while they existed and are kept as the recorded
+> template for any future extension repository — not as a description of
+> anything live. Note in particular that the "published public from the start"
+> departure recorded below is the one whose consequences are worth reading
+> back: both repos that took it are gone within days of their first release.
 
 Both `urlcode-dynamic-link` and `urlcode-middleware` follow `GOVERNANCE.md`
 and `AGENTS.md` as written, with one explicit decision recorded here per
@@ -176,7 +202,8 @@ AGENTS.md's "do not publish packages without an explicit decision":
   admins or automation, CODEOWNERS recording ownership. CI/release workflow
   shape copied from core's `release.yml` (candidate build → audit → pack →
   attest → publish via trusted publisher, no long-lived npm token), per the
-  pattern `docs/NEXT-STEPS.md` §2.1 already used for `auth`/`admin`/`ui`.
+  pattern §2.1 of the archived plan (`docs/archive/2026-09-19/NEXT-STEPS.md`)
+  already used for `auth`/`admin`/`ui`.
   CodeQL required on main, secret scanning and push protection on, same as
   core.
 - **Published public from the start** — both the GitHub repo and the npm
@@ -225,9 +252,10 @@ system tax." The real costs are narrower and different for each:
   cost described above still applies, in full, to whichever specific
   `middleware:` wrap a developer explicitly opts into `sandbox: true` — and
   the same mitigation still matters there: native declarative primitives
-  (`docs/NEXT-STEPS.md`'s Phase 4.2 `auth: { required: true, roles: [...] }`
-  direction) reduce how much logic ever needs to reach for the sandboxed
-  opt-in at all, for the cases where a developer does judge it warranted.
+  (the Phase 4.2 `auth: { required: true, role: ... }` direction in the
+  archived plan, `docs/archive/2026-09-19/NEXT-STEPS.md`) reduce how much logic
+  ever needs to reach for the sandboxed opt-in at all, for the cases where a
+  developer does judge it warranted.
 
 ## Other core pieces considered and set aside
 
@@ -253,14 +281,17 @@ part of the smallest complete product:
   them would shrink core below the "complete product on its own" bar rather
   than trim it.
 - **Management API / operator grants / credential policy** — foundation that
-  extensions themselves depend on (`docs/MANAGEMENT-SECURITY.md`,
+  extensions themselves depend on (`docs/archive/2026-09-19/MANAGEMENT-SECURITY.md`,
   `docs/FUNCTION-SECURITY.md`); moving it out would mean extracting the thing
   the extraction pattern relies on.
 
 Nothing else in core matches the `link`/`middleware` shape today. If a third
-candidate is going to be found, `docs/REPETITION-LOG.md`'s discipline (`docs/NEXT-STEPS.md`
-Phase 6 — extract from observed repetition, not speculation) is the more
-defensible way to find it than continuing to eyeball the handler list.
+candidate is going to be found, the repetition-log discipline of Phase 6 in the
+archived plan (`docs/archive/2026-09-19/NEXT-STEPS.md`) — extract from observed
+repetition, not speculation — is the more defensible way to find it than
+continuing to eyeball the handler list. That plan records Phase 6 as never
+started, and no `docs/REPETITION-LOG.md` was ever written, so the log itself
+would have to be started before it could inform the decision.
 
 Recommendation: before either Phase 2 begins, attach `urlcode-auth`,
 `urlcode-admin` and `urlcode-ui` to a session and confirm (a) their actual

package/docs/SPIKE-DEFAULT-TRUST-MODEL.md

@@ -3,8 +3,7 @@
 Status: **decided by the maintainer and implemented in `0.4.0-alpha.2`**
 (`sandbox`/`sandboxReason` in `schemas/urlcode.schema.json`; see the
 `0.4.0-alpha.2` entry in [the roadmap](../ROADMAP.md) and the resulting contract
-in [function security](FUNCTION-SECURITY.md)). `0.4.0-alpha.2` is not yet
-published to npm. This overturns an
+in [function security](FUNCTION-SECURITY.md)). The release is published; this file retains the decision rationale. This overturns an
 explicit, previously-stated project rule — see "What this reverses" below —
 so treat it as a deliberate, recorded policy change, not a code cleanup. The
 body below is preserved as written at decision time; where it calls downstream
@@ -153,11 +152,14 @@ with `add_repo` before treating it as settled.
   and `peers.json` in `auth`/`admin`/`ui` (`docs/SPIKE-CORE-LAYERING.md`'s
   §2.2 reference) should pin deliberately to a core version that includes
   this change, not inherit it silently on a routine bump.
-- **`urlcode-dynamic-link` (built and published since; was planned when this was written): unaffected.** It's a
+- **`urlcode-dynamic-link` (built and published after this was written, then retired, unpublished and deleted in September 2026): moot.** It was a
   mount-based extension like `auth`, not a `function`/`middleware` consumer —
   nothing here changes its design.
-- **`urlcode-middleware` (built and published since; was planned when this
-  was written): same rule applies — decided.** First-party middleware is trusted by default, exactly like
+- **`urlcode-middleware` (built and published since, then retired, unpublished
+  and deleted in September 2026): the rule outlived the package — decided.**
+  The decision below was made for that package but is not about it: it governs
+  core's own native `middleware:` array, which is where per-route middleware
+  lives now that the extension package is gone. First-party middleware is trusted by default, exactly like
   `function`; `sandbox: true` is the same opt-in a developer reaches for
   when a specific `middleware:` wrap genuinely warrants it (e.g. it's
   processing input from a source the developer doesn't fully trust). This