@jimhoyd/urlcode 0.4.0-alpha.2 → 0.4.1

package/dist/types/project-dependencies.d.ts

@@ -0,0 +1,78 @@
+/**
+ * Exact dependency pins for a generated application.
+ *
+ * `urlcode init --with` resolves whatever `@jimhoyd/urlcode-<name>` packages are already installed beside the
+ * invoking directory. Without a manifest the generated site records nothing about which versions it was built
+ * against, so a later `npm install @jimhoyd/urlcode-auth` in that site can resolve a different set (#212). This
+ * module reads the versions that were actually resolved, validates the whole set against the packages' own
+ * declared `peerDependencies`, and renders a `package.json` pinning every one of them exactly.
+ *
+ * It never runs a package manager: generating a lockfile stays an explicit `npm install` the operator runs after
+ * reviewing the manifest. It also never imports an extension implementation -- only package metadata is read, by
+ * a name the caller supplied -- so core's generic extension boundary is unchanged.
+ */
+export declare const CORE_PACKAGE = "@jimhoyd/urlcode";
+interface Version {
+    major: number;
+    minor: number;
+    patch: number;
+    pre: readonly (string | number)[];
+}
+export declare function parseVersion(value: string): Version | null;
+export declare function compareVersions(a: Version, b: Version): number;
+export declare function satisfiesRange(version: string, range: string, context?: string): boolean;
+export interface InstalledPackage {
+    name: string;
+    version: string;
+    directory: string;
+    peers: Record<string, string>;
+    optionalPeers: ReadonlySet<string>;
+    node: string | undefined;
+}
+/**
+ * Walks `node_modules` upwards from the invoking directory, exactly like Node's own resolution but reading the
+ * package's manifest rather than its entry point. Reading the manifest directly (instead of resolving the entry)
+ * means a package whose `exports` does not expose `./package.json` is still inspectable, and nothing in the
+ * package is loaded or executed.
+ */
+export declare function findInstalledPackage(name: string, from: string): Promise<InstalledPackage | null>;
+/** The version of the runtime executing this command; that is the version a generated site is pinned to. */
+export declare function runningCore(): Promise<InstalledPackage>;
+export interface DependencyPin {
+    name: string;
+    version: string;
+    specifier: string;
+    /** True when the specifier is a local path or tarball rather than a registry version. */
+    local: boolean;
+    /** `runtime` is core, `extension` was named in --with, `peer` was pulled in by a package's peerDependencies. */
+    role: 'runtime' | 'extension' | 'peer';
+}
+export interface DependencySet {
+    pins: DependencyPin[];
+    /** Exactly what goes into the generated `dependencies` block, sorted by name. */
+    dependencies: Record<string, string>;
+    /** Highest recognized `engines.node` floor across the set, or undefined when none was expressed as `>=x.y.z`. */
+    node: string | undefined;
+    /** True when any pin points at a local path or tarball. */
+    local: boolean;
+}
+export interface DependencyOptions {
+    cwd?: string | undefined;
+    /** `--pin <package>=<specifier>`: an operator-chosen specifier, for local tarballs and mirrors. */
+    overrides?: ReadonlyMap<string, string> | undefined;
+}
+export declare function parsePin(value: string): [string, string];
+/**
+ * Resolves core plus every named extension and their declared peers, then validates the whole set against every
+ * declared peer range before returning. Compatibility is judged as a set: a mismatch anywhere refuses, listing
+ * every mismatch rather than the first.
+ */
+export declare function collectDependencySet(names: readonly string[], packageNames: readonly string[], { cwd, overrides }?: DependencyOptions): Promise<DependencySet>;
+/** The generated manifest: private, module type, exact pins, and nothing that runs a package manager. */
+export declare function renderPackageManifest(directory: string, set: DependencySet): string;
+/**
+ * The install step is printed, never run: generating `package-lock.json` executes a package manager, which
+ * resolves and downloads code, so it stays the operator's explicit action after reviewing the manifest.
+ */
+export declare function installSteps(directory: string, set: DependencySet): string[];
+export {};

package/dist/types/readiness.d.ts

@@ -8,6 +8,8 @@ export type HandlerName = 'extension' | 'proxy' | 'conditional' | 'redirect' | '
 /** One configured route as the inventory reports it: a PlanInventoryEntry with the handler kind named. */
 export interface RouteInventory extends PlanInventoryEntry {
     handler: HandlerName | undefined;
+    /** Always reported here, so a trust change is visible in `routes` and its diff. */
+    sandbox: boolean;
     /** Non-blocking `audit` observations about this route (e.g. a webhook-shaped
      * route with no declared `sandbox`/`sandboxReason`); never affects `ready`. */
     advisories?: string[];

package/dist/types/trusted-functions.d.ts

@@ -2,11 +2,9 @@ import type { FunctionRoute } from './function-sources.ts';
 import type { FunctionContext, FunctionResult } from './functions.ts';
 import type { GuestRequestPayload } from './guest-api.ts';
 import type { HandlerResult } from './http-response.ts';
-import type { LogFn } from './types.ts';
 export interface TrustedFunctionsOptions {
     timeoutMs?: number | undefined;
     maxBytes?: number | undefined;
-    log?: LogFn | undefined;
 }
 interface TrustedDefinition {
     source: string;
@@ -16,9 +14,8 @@ export type TrustedRoute = FunctionRoute<TrustedDefinition>;
 export declare class TrustedFunctions {
     timeoutMs: number;
     maxBytes: number;
-    log: LogFn;
     private readonly epoch;
-    constructor({ timeoutMs, maxBytes, log }?: TrustedFunctionsOptions);
+    constructor({ timeoutMs, maxBytes }?: TrustedFunctionsOptions);
     start(routes: TrustedRoute[]): Promise<this>;
     private loadExport;
     execute(route: TrustedRoute, request: GuestRequestPayload, context: FunctionContext, native: HandlerResult | undefined): Promise<FunctionResult>;

package/dist/types/types.d.ts

@@ -378,7 +378,7 @@ export type PolicyChain = {
     describe: PolicyInventory;
 } & Partial<PolicyStates>;
 export type RouteState = 'active' | 'disabled' | 'expired';
-/** One route in the audit inventory: its handler kind, methods and lifecycle state. */
+/** One route in the audit inventory: its handler kind, methods, execution mode and lifecycle state. */
 export interface PlanInventoryEntry {
     path: string;
     handler: string | undefined;
@@ -387,6 +387,13 @@ export interface PlanInventoryEntry {
     policies: string[];
     generated?: string;
     state: RouteState;
+    /** The route's execution mode: `true` when its `function`/`middleware` chain runs in the
+     * QuickJS sandbox, `false` when it runs trusted in-process. Route-level, because the mode
+     * applies to the whole chain — a native handler with `middleware` has one too. Optional
+     * only at the report-parsing boundary: reports written before it existed omit it. */
+    sandbox?: boolean;
+    /** The route's declared `sandboxReason`, when it has one. */
+    sandboxReason?: string;
 }
 export interface TestPlan {
     inventory: PlanInventoryEntry[];

package/dist/types.js

@@ -199,9 +199,16 @@
 // consume it need not import the host module that produces it.
 
                                                            
-/** One route in the audit inventory: its handler kind, methods and lifecycle state. */
+/** One route in the audit inventory: its handler kind, methods, execution mode and lifecycle state. */
                                      
                                                                                                                                               
+                                                                                           
+                                                                                            
+                                                                                          
+                                                                                       
+                    
+                                                               
+                         
  
                            
                                                                                                 

package/dist/typescript-authoring.js

@@ -23,16 +23,20 @@ const SANDBOX_MODULE_LIMIT=128,SANDBOX_MODULE_BYTE_LIMIT=1048576,SANDBOX_TOTAL_B
 export async function buildTypeScriptProject(project        ,output        ,{dryRun=false}                              ={})                                 {
   const root=await realpath(project),loaded=await loadDocument(root),files=new Map                      (),modules=new Map               ();
   const {default:ts}=await import('typescript');
-  // Per-path trust, so a module visited once (recursively, from its importer)
-  // is never reprocessed under a different trust level.
-  const moduleTrust=new Map                ();
+  // Which trust levels a module has already been visited under, so a graph
+  // reachable from both a sandboxed and a trusted route is validated under each
+  // route's own rules exactly once instead of being refused outright. The
+  // module is still emitted once; `emittedBy` keeps target-name collisions
+  // between *different* sources refused.
+  const moduleTrust=new Map                     (),emittedBy=new Map               ();
   let sandboxedSourceBytes=0,sandboxedModuleCount=0,assetBytes=0;
   await init;
   async function collect(path        ,sandboxed         )                {
     authoringPath(path);assert(/\.(?:ts|js|mjs)$/.test(path) && !path.endsWith('.d.ts'),'Guest source must be .ts, .js or .mjs');
-    const seen=moduleTrust.get(path);
-    if(seen!==undefined){assert(seen===sandboxed,'Module is imported by both a sandboxed and a trusted route');return;}
-    moduleTrust.set(path,sandboxed);
+    let visited=moduleTrust.get(path);
+    if(!visited){visited=new Set();moduleTrust.set(path,visited);}
+    if(visited.has(sandboxed))return;
+    visited.add(sandboxed);
     let bytes        ;
     if(sandboxed){
       assert(sandboxedModuleCount<SANDBOX_MODULE_LIMIT,'Function module limit exceeded');sandboxedModuleCount++;
@@ -93,7 +97,14 @@ export async function buildTypeScriptProject(project        ,output        ,{dry
       }
     }
     for(const edit of edits.sort((a,b)=>b.start-a.start))code=code.slice(0,edit.start)+edit.value+code.slice(edit.end);
-    const target=emitted(path);assert(!files.has(target),'Guest output module collision');files.set(target,code);
+    // A module reachable from both trust levels is transpiled twice (once per
+    // rule set) but emitted once. The two results agree: the sandbox rules are
+    // strictly stricter, so anything the trusted pass would leave alone —
+    // bare/dynamic specifiers, `import.meta` — fails the sandboxed pass and
+    // aborts the whole build before either emission is published.
+    const target=emitted(path),previous=emittedBy.get(target);
+    assert(previous===undefined||previous===path,'Guest output module collision');
+    emittedBy.set(target,path);files.set(target,code);
   }
   for(const route of Object.values(loaded.routes))for(const definition of routeFunctions(route)){
     await collect(definition.source,!!route.sandbox);definition.source=emitted(definition.source);

package/docs/AI-AUTHORING.md

@@ -25,7 +25,11 @@ fields or bypass target limits or operator grants. See [the design principle](PR
 6. [Readiness](READINESS.md), [capacity](CAPACITY.md), [DDoS/recovery](RESILIENCE.md).
 7. [The framework](FRAMEWORK.md) for accounts, administration and presentation:
    `extensions.<name>` blocks and `extension` mounts are the only YAML those
-   packages need; their configuration is documented in their own repositories.
+   packages need. [Composing a site](COMPOSING-A-SITE.md) is the map of what a
+   consumer may then change: the `config` each package accepts, the
+   presentation overrides under `ui/`, the project functions its lifecycle
+   hooks call, and when a requirement instead needs a new extension in
+   TypeScript.
 
 The root [llms.txt](../llms.txt) is a compact discovery index; the generated
 [llms-full.txt](../llms-full.txt) concatenates the authoring documents above in
@@ -106,7 +110,7 @@ The benchmark operates locally; it is not a load test of an external deployment.
 | Parameter validation and JSON body syntax checks | Full OpenAPI or JSON Schema validation of request bodies |
 | Local test/audit/benchmark | Route-local YAML tests, managed monitoring, production load certification |
 | Local/self-hosted runtime; limited AWS/Vercel/Cloudflare implementations with local tests | Verified provider deployments or full cross-provider parity |
-| File authoring and snapshot reload | General guest storage broker; stored short links (moving to a future `urlcode-dynamic-link` extension package, not yet published) |
+| File authoring and snapshot reload | General guest storage broker; stored short links (no supported package; the `urlcode-dynamic-link` extension was retired) |
 | Optional host `policies` (`throttle`, `agents`, `security`, `compression`, `cache`) and reusable `profiles` | Plugins named in YAML, shared multi-instance counters, CORS, verified-bot checks |
 | Optional top-level `site` (`robots`, `sitemap`, `favicon`, `securityTxt`, `llms`) generating native routes | Per-route `noindex` field, sitemap index files, `humans.txt`, signed `security.txt` |
 
@@ -240,9 +244,12 @@ Put that justification where tooling can see it, not only in a source
 comment: an optional `sandboxReason` string on the route (up to 500
 characters, `schemas/urlcode.schema.json`) records why a route needs
 isolation, or why it is safe to trust, regardless of whether `sandbox` is
-`true` or `false`. `urlcode explain`/`context` surface it next to the
-route's `sandbox` boolean, so the trust decision has a reviewable trail
-without reading every route's source file:
+`true` or `false`. `urlcode explain`/`context`, the manifest and the
+`routes` inventory all surface it next to the route's `sandbox` boolean —
+per route, not per handler, so a native handler that runs `middleware`
+reports its execution mode too, and `routes --compare` shows a flip between
+trusted and sandboxed execution as a changed route. The trust decision has a
+reviewable trail without reading every route's source file:
 
 ```yaml
 routes:
@@ -323,8 +330,9 @@ trust (adding `sandbox: true` without saying why, or relying on the trusted
 default for code that plainly needed isolation) to work around them.
 
 There is no native `link` handler or `dynamicLinks` project flag; both were
-removed. Report a request for live stored links as a gap pending the future
-`urlcode-dynamic-link` extension package rather than inventing a `link` field.
+removed. The `urlcode-dynamic-link` extension package that briefly owned them
+has been retired and unpublished, so there is no supported replacement. Report a
+request for live stored links as a gap rather than inventing a `link` field.
 
 See [capabilities and normalized route representation](CAPABILITIES.md) for the target catalog,
 programmatic compatibility analysis and provider verification limits.

package/docs/ASSETS.md

@@ -2,7 +2,8 @@
 
 Native file handlers are implemented in 0.1.0-alpha.3. They work in the local
 Node runtime and self-hosted process/container. Provider adapters remain planned.
-They do not run user functions or expose filesystem APIs to sandboxed code.
+They do not run user functions or expose filesystem APIs to guest code, trusted
+or sandboxed.
 
 ```yaml
 version: "1"

package/docs/AUTH-BACKUP.md

@@ -0,0 +1,32 @@
+# Auth backup and restore platform guarantees
+
+`createBackup({database,destination,projectRoot})` and
+`restoreBackup({backup,destination,projectRoot})` use SQLite's online backup API
+in a bounded worker. They include committed WAL pages, validate integrity and
+foreign keys, and publish to a new path without overwriting an existing file.
+Both source and destination must remain outside the served project. See the
+[auth operator commands](../packages/auth/README.md#operations-and-recovery).
+
+The completed snapshot is flushed through a writable file handle before it is
+linked into its destination. Windows requires write access for this flush;
+opening the snapshot read-only fails with `EPERM`. File flush errors fail the
+operation rather than being ignored.
+
+On POSIX systems the containing directory is also flushed after publication.
+Node's filesystem API does not provide the equivalent directory-handle flush
+used here on Windows, so Windows does not receive that extra directory-entry
+crash-durability guarantee. A successful Windows backup verifies and flushes
+file contents; it is not proof that the new filename survives abrupt power
+loss. Verify the backup exists and perform an isolated restore rehearsal before
+depending on it. CI does not simulate power loss.
+
+POSIX directory/file modes are checked where supported. Windows operators must
+restrict the operator data and backup directories with filesystem ACLs; POSIX
+mode bits cannot establish Windows privacy. Keep encryption and CSRF keys and
+reviewed configuration separately backed up. Restore to an isolated new path,
+and review restored sessions and revocation state before reopening traffic.
+
+A failed auth service initialization waits for its SQLite worker to terminate
+before rejecting. After a configuration rejection, callers can retry or clean up
+the database without racing that failed opener's file handle. Configuration
+identity checks and their error codes are unchanged.

package/docs/AWS.md

@@ -11,6 +11,15 @@ self-hosted Node lifecycle, and a `sandbox: true` route would pay worker and
 WASM startup on every cold start. Both are refused at activation with the route
 named, never per request, trusted or sandboxed alike.
 
+That refusal is a settled position, not a gap awaiting an adapter: per-route
+Lambda compilation was considered and declined
+([the decision](OPEN-DECISIONS.md#accepted-one-node-deployment-per-project),
+[the analysis behind it](archive/2026-09-19/SPIKE-LAMBDA-COMPILE.md)). A project that uses
+`function` or `middleware` deploys instead as one trusted Node process — a
+container or a VM running the project as it runs locally — which supports every
+route type today. That process can run on AWS: ECS, EC2 and App Runner all
+serve it. The decision is about the execution model, not about avoiding AWS.
+
 A working project is in [`examples/aws/`](../examples/aws/).
 
 ## Set it up

package/docs/BEST-PRACTICES.md

@@ -165,8 +165,10 @@ accepting any user-controlled URL. Keep modules free of top-level work other tha
 simple definitions: initialization runs during validation and fresh invocations.
 
 Prefer pure helpers with explicit inputs and outputs. Module globals are not a
-cache, database, session store or rate limiter: guest state resets per request.
-Review [sandbox constraints](FUNCTION-SECURITY.md) before choosing dependencies.
+cache, database, session store or rate limiter: guest state resets per request
+regardless of trust mode. If a route declares `sandbox: true`, review
+[sandbox constraints](FUNCTION-SECURITY.md) before choosing dependencies —
+trusted (default) routes have ordinary Node module access instead.
 
 ## Middleware should have one clear responsibility
 
@@ -182,8 +184,10 @@ export default async function responseHeaders(request, context, next) {
 
 Use middleware for reusable behavior around a handler, not to conceal the entire
 application flow. Prefer YAML headers for fixed route-specific headers; this
-example demonstrates a shared wrapper, but native YAML avoids sandbox overhead
-when no custom code is needed. Keep middleware order explicit in each route.
+example demonstrates a shared wrapper, but native YAML avoids any
+function/middleware invocation overhead when no custom code is needed —
+including the extra cost of `sandbox: true` where that is declared. Keep
+middleware order explicit in each route.
 
 Always return a Response. Call `await next()` once when continuing, or return
 an early Response when intentionally stopping. Do not launch unawaited work or
@@ -217,8 +221,9 @@ For the two-route feature layout above:
 ```
 
 Additional ordinary JavaScript unit tests for pure helpers are your project's
-choice. Unit tests alone do not verify sandbox compatibility: always exercise
-HTTP behavior through URLCode too. Keep large fixture generation explicit and
+choice. Unit tests alone do not verify runtime compatibility — including the
+guest API restrictions of a route declaring `sandbox: true` — or HTTP framing:
+always exercise HTTP behavior through URLCode too. Keep large fixture generation explicit and
 deterministic if you add your own tooling; nested test directories and JSON
 fragments are not automatically discovered or merged by URLCode.
 
@@ -238,9 +243,12 @@ Update expected route counts deliberately when adding or removing a route.
   YAML anchors, shell expansion or generated credentials for convenience.
 - Deployment limits, TLS, DNS, DDoS filters and worker tuning belong to operations,
   not invented route fields. Document them separately from portable behavior.
-- Live short-code records need durable storage core does not have; that is
-  moving to a future `urlcode-dynamic-link` extension package, not yet
-  published. General session/application storage remains future work.
+- Live short-code records need durable storage core does not have. The
+  `urlcode-dynamic-link` extension provided it and has been retired; its
+  published `0.1.0-alpha.1` pins core `0.4.0-alpha.1` exactly and so cannot be
+  installed beside `0.4.0-alpha.2`. Treat stored short links as unsupported
+  until that work lands somewhere else. General session/application storage
+  remains future work.
 
 ## Refactor without changing the public contract
 

package/docs/CAPABILITIES.md

@@ -166,7 +166,7 @@ proxy headers and signal definitions. Resolved egress headers are private runtim
 state and must never be serialized. Capability analysis itself adds no authority
 and does not run in the request path.
 
-See the [repository review and incremental plan](NEXT-PHASE-PLAN.md) for the
+See the [repository review and incremental plan](archive/2026-09-19/NEXT-PHASE-PLAN.md) for the
 implementation status. Provider deployment tests, independent security review and
 operational soak/recovery proof are separate work.
 

package/docs/CI-FOLLOWUP-2026-09-19.md

@@ -0,0 +1,97 @@
+# CI and release follow-up, September 19, 2026
+
+This is the evidence and disposition for [#185](https://github.com/jimhoyd-com/urlcode/issues/185),
+after the Windows fixes (#190) and matrix change (#192). It does not authorize
+publication or change required checks.
+
+## Reproducible measurements
+
+```sh
+npm run ci:history -- 100 2026-09-19 > /tmp/ci-history.json
+npm run ci:report -- 35482828280
+```
+
+The history helper reads GitHub through `gh`, with four concurrent requests at
+most. It does not dispatch new runs. Increase the limit (maximum 1,000) as more
+history accumulates. Use a date cutoff after the rollout when comparing the
+same workflow generation. It groups by event, inferred lane and exact matrix,
+reports counts and nearest-rank p50/p95, and flags groups with fewer than 20
+successful first attempts. Failures/cancellations remain visible but are excluded
+from successful-run percentiles. Reruns are excluded because run creation time
+includes the human delay before retrying. Earlier attempts are not a complete
+usage ledger. Raw job/step durations and run URLs remain in the output.
+
+Workflow elapsed time ends at the last active job's completion. Runner-minutes
+sum overlapping job execution durations: they are neither wall time nor billed
+minutes. Job-creation-to-start is an observed scheduling interval, not a guarantee
+of pure runner queue time. Workflow-creation-to-start also includes dependencies.
+Missing timestamps remain missing; they are never treated as zero.
+
+The initial 100-run sample spans September 19 04:59 UTC through September 20
+02:00 UTC. Successful first-attempt results:
+
+| Configuration | Samples | Wall p50 / p95 | Runner-minute p50 / p95 |
+| --- | ---: | --- | --- |
+| Historical combined main, 9 jobs | 20 | 8m27s / 9m04s | 49.82 / 53.62 |
+| Historical combined PR, 3 jobs | 40 | 6m12s / 8m52s | 17.28 / 24.57 |
+| Split full main, 18 jobs | 1 | 7m36s / 7m36s | 74.30 / 74.30 |
+| Split compact main, 10 jobs | 1 | 6m48s / 6m48s | 43.20 / 43.20 |
+| Split compact PR, 10 jobs | 2 | 6m38s / 7m15s | 40.23 / 43.58 |
+
+Historical groups contain changing code and workflow revisions; they are context,
+not a controlled experiment. The sample includes no classified docs-only runs.
+It cannot satisfy the 20-run acceptance criterion for the new lanes. Do not
+manufacture 20 redundant workflow runs to fill the sample.
+
+The [compact main run](https://github.com/jimhoyd-com/urlcode/actions/runs/35482828280)
+used 31.1 fewer runner-minutes than the preceding
+[full matrix main run](https://github.com/jimhoyd-com/urlcode/actions/runs/35482515877),
+an observed 41.9% reduction between two runs, not an established long-term rate.
+Its Windows core job took 377 seconds: 258 in `npm test`, 58 in package smoke,
+13 in installation. Linux Node 22 spent 300 of its 355 seconds in `npm test`.
+The next useful optimization target is the runtime suite, not removing static,
+container, audit or provenance checks. CLI subcommands are separate steps in the
+raw report. File-level profiling is still needed before choosing balanced shards;
+extra shards would add setup and runner pressure.
+
+## Changes delivered in this follow-up
+
+- A Windows validation failure exposed rejected auth initialization returning
+  before its worker terminated. The caller now awaits termination before receiving
+  the original error; a deterministic regression test proves the ordering.
+- `ci:history` makes the remaining baseline measurable without new CI jobs.
+- Auth/admin release instructions now use scoped monorepo tags and the correct
+  trusted-publisher workflow filenames. Package agent guides file issues here
+  and point documentation at root `docs/`.
+- Optional evals checks its credential before checkout/setup/install, and retains
+  artifacts for 14 days. This avoids unused setup; it does not remove the weekly
+  quality check or claim measured savings from a workflow with no prior runs.
+- The manual signed candidate builds all four tarballs and installs them together
+  in a temporary consumer outside the workspace. It verifies the peer dependency
+  tree, installed versions, public imports, and `init --with ui,auth,admin`.
+  `train.json` records package SHA-512 integrity and the source commit; the
+  candidate manifest/checksums and provenance include the extension archives.
+  Failure stops the candidate before attestation/upload. Nothing is published.
+
+The candidate validates the proposed package set, not live-provider behavior or
+registry OIDC. Per-package release workflows still prepare their own archives
+and retain their original bytes for retries; candidate archives are not silently
+substituted for published release bytes. Before a release, dispatch the candidate
+at the selected main commit, then the full verification workflow, and inspect
+both results before using the authorized coordinator.
+
+## Remaining decisions and external validation
+
+| Item | Disposition |
+| --- | --- |
+| Windows packaging/process coverage | Delivered in #190/#192; Node 24 on relevant PRs/main, all supported versions nightly/manually. |
+| 20-run baseline per new lane | Wait for organic runs, then rerun the helper with a rollout cutoff. |
+| Dependency-aware package selection | Keep conservative coverage for now. UI feeds auth/admin; auth feeds admin; core extension/CLI/scaffold changes affect the full composition. A package map must include integration, generated styles, peers and tooling, not just changed directory names. |
+| Changeset/no-release enforcement | Still open. Define explicit core release intent as well as workspace Changesets; require reviewed reasons for no-release cases before implementing a gate. Blanket source-path rules would misclassify tests/tooling and root core is not versioned by Changesets. |
+| Move core into `packages/core` | Separate migration, not a prerequisite for fast CI. Root-relative build, package files, CLI, Docker and starter paths make this higher risk than keeping the explicit root inventory. |
+| OIDC and retained-artifact retry | Needs the next explicitly authorized release. No synthetic run proves npm's trust configuration or partial publication recovery. |
+| Historical GHCR image labels/digests | Blocked on read access: anonymous registry lookup returned 403; organization package API explicitly requires `read:packages`. No labels/digests were verified and no images or publication settings changed. The repository has no `PUBLISH_CONTAINER` variable; inherited organization variables could not be inspected with this credential. |
+| Dependabot grouping / unchanged nightly reuse | No change yet. Measure update PR fanout before grouping; unchanged source can still acquire new advisory findings, so reusing old verification indiscriminately would hide them. |
+
+Keep #185 open for these acceptance items. The remaining items are not evidence
+that a publish or recovery rehearsal has already succeeded.