@bakery-framework/cli 2.0.0-alpha.9 → 2.0.0-rc.2

package/README.md

@@ -32,15 +32,15 @@ There is no `--port` flag. The port resolves as `PORT` → `port` in
 fallback: `PORT=3000x` exits 1 instead of binding somewhere random.
 
 For a standalone schema sync in a deploy step, drive `SyncService` from
-`@bakery-framework/orm/sync` directly — `--sync` starts a server afterwards.
+`@bakery-framework/orm/sync` directly: `--sync` starts a server afterwards.
 
 ## License
 
-MIT with the Commons Clause v1.0 — see [LICENSE](./LICENSE).
+MIT with the Commons Clause v1.0. See [LICENSE](./LICENSE).
 
-**Not an OSI-approved licence.** The Commons Clause removes the right to *sell*
-the software — meaning to charge for a product or service whose value derives
+**Not an OSI-approved license.** The Commons Clause removes the right to *sell*
+the software: meaning to charge for a product or service whose value derives
 substantially from it, hosting and support included. Everything else the MIT
-licence grants is unchanged: use it, modify it, ship it inside your own product.
-If your organisation only permits OSI-approved dependencies, this will not pass
+license grants is unchanged: use it, modify it, ship it inside your own product.
+If your organization only permits OSI-approved dependencies, this will not pass
 that check.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/cli",
-  "version": "2.0.0-alpha.9",
+  "version": "2.0.0-rc.2",
   "description": "Bakery entry point and process supervision: mode dispatch, dev watcher, cluster.",
   "keywords": [
     "bakery",
@@ -36,13 +36,13 @@
     "!src/tests"
   ],
   "engines": {
-    "bun": ">=1.3.14"
+    "bun": ">=1.4.0"
   },
   "dependencies": {
-    "@bakery-framework/core": "^2.0.0-alpha.9"
+    "@bakery-framework/core": "^2.0.0-rc.2"
   },
   "peerDependencies": {
-    "@bakery-framework/orm": "^2.0.0-alpha.9"
+    "@bakery-framework/orm": "^2.0.0-rc.2"
   },
   "peerDependenciesMeta": {
     "@bakery-framework/orm": {

package/src/args.ts

@@ -3,7 +3,7 @@
  *
  * Split out of `index.ts` so it can be tested: that file is the mode
  * dispatcher, and importing it boots a server. Nothing here reads
- * `process.argv` — the caller passes the slice, which is also what lets a test
+ * `process.argv`: the caller passes the slice, which is also what lets a test
  * state the argv it means.
  */
 
@@ -35,7 +35,7 @@ export function autoThreadCount(): number {
  * `handleThreadsMaster` with one worker.
  *
  * Both spellings of each flag are accepted (`--threads 4`, `--threads=4`, and
- * the `-t` forms). A flag with a non-numeric or absent value is not an error —
+ * the `-t` forms). A flag with a non-numeric or absent value is not an error:
  * it falls back to `autoThreadCount()`, so `--threads --dev` asks for the
  * default rather than rejecting. `Math.max(1, …)` is what keeps `--threads 0`
  * from requesting a cluster with no workers in it.

package/src/dev.ts

@@ -22,7 +22,7 @@ try {
 
   config = await initConfig()
   // Still before initImportMap(): a plugin's setup() may contribute entries.
-  // setupPlugins() memoises, so setupServer()'s later call is a no-op here.
+  // setupPlugins() memoizes, so setupServer()'s later call is a no-op here.
   await setupPlugins()
   await initImportMap()
   initHostImportMaps()
@@ -74,7 +74,7 @@ if (hasORM()) {
       serveLog.SCHEMA_SYNC_SKIP()
       // Only on the skip path. When a sync runs it reports drift itself, from
       // the plan it just built; here nothing else would ever look. Measured at
-      // 2.7ms median against apps/example (4 tables) — it is one introspection
+      // 2.7ms median against apps/example (4 tables): it is one introspection
       // pass, so it grows with table count, which is why it is not on the path
       // that is about to introspect anyway.
       const { initDB, connection } = await import(

package/src/index.ts

@@ -14,15 +14,63 @@ const isThreadWorker = import.meta.env.THREAD_WORKER
 
 const threadsOption = parseThreadsOption(process.argv.slice(2))
 
+/**
+ * `--help` before anything else, because everything else starts a server.
+ *
+ * There was no help branch at all: `bakery --help` fell through to `./prod`,
+ * booted a production server, bound the configured port and sat there. On a
+ * machine where that port is already taken it fails with a bind error, and on
+ * one where it is free it silently *takes* it: either way the user asked what
+ * the flags were and got a running service.
+ *
+ * Printed with `console.log` and not the structured logger, for the reason
+ * CLAUDE.md records as one of the two standing exceptions: usage text is
+ * program output, not a log line, and it goes to stdout so it can be piped.
+ */
+if (process.argv.includes('--help') || process.argv.includes('-h')) {
+  console.log(`
+Usage: bakery [--dev] [--sync] [--threads N] [--port N]
+
+Runs the application in the current directory: the one whose
+\`server.config.ts\` sits beside it.
+
+Flags:
+  --dev             Development: a supervisor that watches files, compiles on
+                    demand and reloads the browser. Without it, production.
+  --sync, -s        Run the schema sync before starting. Requires
+                    @bakery-framework/orm; it is an error rather than a skip
+                    when that is missing, because asking for a sync and
+                    silently not doing one looks like it worked.
+  --threads N, -t N Fork a cluster of N workers. Production only: ignored
+                    under --dev. THREAD_ID 0 owns the startup banner.
+  --port N, -p N    Listening port. Overrides \`port\` in server.config.ts and
+                    the PORT environment variable.
+  --help, -h        This.
+
+Schema commands have their own help: \`bun run db:sync --help\`.
+`)
+  process.exit(0)
+}
+
 // Before any mode takes over, and before the config is read: `applyPortFlag`
 // writes `process.env.PORT`, which is what the worker, the startup banner and
-// the dev master's advertised URL all resolve from — and what the spawned dev
+// the dev master's advertised URL all resolve from, and what the spawned dev
 // worker and the cluster Workers inherit. Doing it here means none of them
 // needed changing.
 applyPortFlag()
 
 if (
   (process.argv.includes('--sync') || process.argv.includes('-s')) &&
+  // **Not in development, where `dev.ts` owns the decision.** Under `--dev`
+  // this file is the watcher master, which then spawns a `--dev-worker` that
+  // reaches `dev.ts`, and that path reads `--sync` as `force`, hashes the
+  // schema sources, decides skip-or-run against the recorded hash and writes
+  // the new one. Running here as well meant `--dev --sync` synced twice per
+  // boot: once blindly in the master and once properly in the worker, against
+  // the same database, with the master's pass doing work the worker was about
+  // to redo. Production keeps this branch, because `prod.ts` does not sync at
+  // all and this is the only thing that answers `--sync` there.
+  !isDev &&
   !isDevWorker &&
   !isThreadWorker
 ) {

package/src/orm.ts

@@ -3,15 +3,15 @@
  *
  * The CLI declares it as an **optional peer**, so an app scaffolded with
  * `--no-orm` never downloads it. Every use of it in this package is already an
- * `await import()`, so its absence is not a module-graph problem — it is a
+ * `await import()`, so its absence is not a module-graph problem: it is a
  * question this file answers once, before anything tries.
  *
  * **Absence and breakage must not be conflated, and telling them apart is the
  * only reason this file exists.** The obvious implementation is to wrap the
  * `await import()` in a try and treat a throw as "not installed", and it is
  * wrong in the direction that costs data: a database that is configured but
- * unreachable, a `DB_URL` with a typo, a schema module that throws at import —
- * all of those would be swallowed as "no ORM here" and the server would boot
+ * unreachable, a `DB_URL` with a typo, a schema module that throws at import.
+ * All of those would be swallowed as "no ORM here" and the server would boot
  * happily with no database and no complaint. `initDB` failing has always been
  * fatal and stays fatal. Only *resolution* failing is soft.
  *
@@ -25,10 +25,10 @@ let resolved: boolean | null = null
 /**
  * True when `@bakery-framework/orm` can be resolved from this package.
  *
- * Memoised: it is asked on the boot path and once more per shutdown, the answer
+ * Memoized: it is asked on the boot path and once more per shutdown, the answer
  * cannot change within a process, and the filesystem walk is not free.
  *
- * `import.meta.dir` is the resolution base on purpose — it is what a real
+ * `import.meta.dir` is the resolution base on purpose: it is what a real
  * `import` from this module would use, so the answer matches what the `await
  * import()` calls below it will actually do. Resolving from `process.cwd()`
  * would ask a different question (does the *app* see it) and could disagree,
@@ -43,7 +43,7 @@ export function hasORM(): boolean {
     resolved = true
   } catch {
     // Not installed. The only expected outcome of this catch, and the reason
-    // it is allowed to be silent — see the note above about what is *not*
+    // it is allowed to be silent. See the note above about what is *not*
     // routed through here.
     resolved = false
   }

package/src/pipeline.ts

@@ -9,7 +9,7 @@ import { retryAfterSeconds } from './rate-limit'
  * They were inline in the `Bun.serve` callback, which is unreachable from a
  * test: `worker.ts` calls `Bun.serve` at module scope, so importing it binds a
  * port. Nothing about them is server-specific, so they live here and the
- * callback calls them — the serve options are otherwise unchanged.
+ * callback calls them: the serve options are otherwise unchanged.
  */
 
 /** The `rateLimit` config with the `false` (disabled) arm removed. */
@@ -24,7 +24,7 @@ export type RateLimitConfig = Exclude<ProcessedAppConfig['rateLimit'], false>
  *
  * The `is.object` guard is load-bearing twice over. `'errorCode' in res` is a
  * `TypeError` on a primitive, and `Try.return`'s failure sentinel is a
- * `symbol` — so the guard is what keeps the rejection path from throwing
+ * `symbol`, so the guard is what keeps the rejection path from throwing
  * inside the code that exists to handle throws. Note `is.object([])` is
  * deliberately `true` (see CLAUDE.md); an array simply has no `errorCode`.
  *
@@ -41,9 +41,9 @@ export function isErrorResult(res: unknown): boolean {
  * Which token bucket this request spends from.
  *
  * The `|| hostname` is not a tidy-up. An empty key is a *valid* string that
- * hashes to one fixed slot, so every client whose IP could not be determined —
+ * hashes to one fixed slot, so every client whose IP could not be determined,
  * which is all of them when `Bakery.server` is not yet assigned, and any of
- * them behind a proxy with `trustProxy` off — would share a single bucket and
+ * them behind a proxy with `trustProxy` off: would share a single bucket and
  * 429 each other. Falling back to the hostname keeps the collision at
  * per-host, which is the coarsest grouping that is still meaningful.
  */
@@ -58,7 +58,7 @@ export function rateLimitKey(
 /**
  * The 429 a rejected request receives.
  *
- * `Retry-After` is whole seconds per RFC 9110 and never 0 — see
+ * `Retry-After` is whole seconds per RFC 9110 and never 0. See
  * `retryAfterSeconds`.
  */
 export function tooManyRequests(refill: number): Response {

package/src/prod.ts

@@ -16,7 +16,7 @@ try {
   )
 
   await initConfig()
-  // Before initImportMap() so plugin-contributed entries land in it; memoised,
+  // Before initImportMap() so plugin-contributed entries land in it; memoized,
   // so the later setupServer() call inside worker.ts does not repeat it.
   await setupPlugins()
   await initImportMap()

package/src/rate-limit.ts

@@ -20,7 +20,7 @@ export const RATE_LIMIT_SLOTS = 1024
  * left 100 reachable buckets out of 1024 with **83% of all keys in bucket 0**.
  * Rate limiting is on by default at `{max: 100, refill: 10}`, so in practice
  * most clients shared one bucket with a sustained ceiling of 10 requests per
- * second — one busy client 429'd everyone else, and an ordinary page load
+ * second, one busy client 429'd everyone else, and an ordinary page load
  * (many requests inside a single refill tick) tripped it on its own.
  *
  * Taking the modulo in bigint space and converting the small result keeps the
@@ -55,13 +55,13 @@ const logState = new LRUCache<string, { last: number; suppressed: number }>(
  *
  * The constraint is availability under flood: stdout writes are effectively
  * synchronous on Windows, so one log line per rejected request hands the flood
- * the limiter just absorbed straight to the logger — the 429 path becomes as
+ * the limiter just absorbed straight to the logger, the 429 path becomes as
  * expensive as the work it was refusing. At most one line per key per
  * `RATE_LIMIT_LOG_WINDOW_MS` instead.
  *
  * Returns `null` when the line must be suppressed, otherwise the number of
  * rejections suppressed since the key's previous line (0 for a first
- * offender). Bounded per convention 6 — the key derives from client-controlled
+ * offender). Bounded per convention 6: the key derives from client-controlled
  * data (IP, or `rateLimit.keyBy`), so the state lives in an LRU and an evicted
  * key simply logs again as if new. Over-logging is the safe direction to be
  * wrong in.
@@ -88,7 +88,7 @@ export function __resetRateLimitLogState(): void {
 
 /**
  * Seconds until the bucket holds a token again, for the 429's `Retry-After`
- * header. Whole seconds per RFC 9110, and never less than 1 — "0" would tell
+ * header. Whole seconds per RFC 9110, and never less than 1: "0" would tell
  * the client to retry immediately, which is the opposite of the point.
  */
 export function retryAfterSeconds(refill: number): number {

package/src/schema-hash.ts

@@ -1,18 +1,18 @@
 /**
  * Hash everything the boot-time schema sync reads: the schema source files
- * (resolved with the same probe order as orm/sync/load.ts — configured path,
+ * (resolved with the same probe order as orm/sync/load.ts, configured path,
  * then the `orm/` folder layout, then a root `schema.ts`) plus the DB target,
  * since switching `DB_URL` changes what "synced" means.
  *
- * Returns `null` for any indeterminate state — a configured path that does not
- * exist, an unreadable file — so `classifySchemaSync` fails closed into
+ * Returns `null` for any indeterminate state (a configured path that does not
+ * exist, an unreadable file), so `classifySchemaSync` fails closed into
  * re-syncing. Total absence of a schema is *not* indeterminate (it is a
  * supported state for the defaults) and hashes to a stable value.
  *
  * `base` defaults to the app's cwd, which is what `dev.ts` wants and the only
  * value it passes. It is a parameter at all because `fs.cwd` is a module-level
  * constant evaluated at import time, so a test cannot reach this function's
- * probe any other way without `process.chdir` before the import — process-global
+ * probe any other way without `process.chdir` before the import: process-global
  * state of exactly the kind convention 9 exists to keep out of the suite.
  *
  * The `@bakery-framework/core/utils` import stays dynamic, as it was inline in

package/src/shutdown.ts

@@ -11,7 +11,7 @@ let running: Promise<void> | null = null
  *
  * The same bound the cluster master applies to a worker's pre-terminate flush,
  * for the same reason it states: *a wedged worker must delay shutdown, not
- * prevent it*. The standalone path did not honour that — `runShutdownSequence()`
+ * prevent it*. The standalone path did not honor that: `runShutdownSequence()`
  * gated `process.exit(0)` with no deadline, so one hook that never settled meant
  * SIGINT never terminated the process and Ctrl-C appeared to do nothing.
  */
@@ -20,7 +20,7 @@ export const SHUTDOWN_TIMEOUT_MS = FLUSH_TIMEOUT_MS
 /**
  * The two teardown steps that close process-wide resources. Behind a seam
  * because a test that ran the real ones would close the cache database and the
- * ORM connection for every test file scheduled after it — see `__setTestDb` in
+ * ORM connection for every test file scheduled after it. See `__setTestDb` in
  * `orm/connection.ts` for the same pattern and the same reason.
  */
 export interface ShutdownTeardown {
@@ -43,7 +43,7 @@ const defaultTeardown: ShutdownTeardown = {
 
 let testTeardown: ShutdownTeardown | null = null
 
-/** Test seam — see `ShutdownTeardown`. */
+/** Test seam. See `ShutdownTeardown`. */
 export function __setTestTeardown(teardown: ShutdownTeardown): void {
   testTeardown = teardown
 }
@@ -55,28 +55,28 @@ export function __resetTestTeardown(): void {
 /**
  * Run every teardown step this process owns, once.
  *
- * Memoised rather than guarded by a boolean: a cluster worker can be asked to
+ * Memoized rather than guarded by a boolean: a cluster worker can be asked to
  * flush by the master *and* receive a signal, and the second caller has to wait
  * for the first run to finish rather than race it or skip it.
  *
  * ## Order
  *
- * 1. `Bakery.config.onShutdown()` — the application's own hook.
- * 2. `Bakery.shutdownHooks` — framework internals (tiered-cache flush, session
+ * 1. `Bakery.config.onShutdown()`: the application's own hook.
+ * 2. `Bakery.shutdownHooks`: framework internals (tiered-cache flush, session
  *    prune timer).
- * 3. `PluginHooks.onShutdown()` — plugins.
- * 4. Resource close — the shared cache database, then the ORM connection.
+ * 3. `PluginHooks.onShutdown()`, plugins.
+ * 4. Resource close: the shared cache database, then the ORM connection.
  *
  * The app goes first because it is the only participant that can still need the
  * framework intact: step 2 flushes the session/cache tier, so an app hook that
  * wants to write a last session value has to run before it, not after. That is
  * also the exact reverse of startup, where `runStartupBanner()` calls
- * `PluginHooks.onStart()` and then `config.onStart()` last — last up, first down.
+ * `PluginHooks.onStart()` and then `config.onStart()` last: last up, first down.
  *
- * Step 4 exists because steps 1–3 all still write. `cache/tiered.ts` used to
+ * Step 4 exists because steps 1 to 3 all still write. `cache/tiered.ts` used to
  * close the shared cache database inside its own step-2 hook, which is
  * registered at module-evaluation time and so runs *first* of all the framework
- * hooks — before every plugin. The analytics plugin's shutdown flush binds that
+ * hooks: before every plugin. The analytics plugin's shutdown flush binds that
  * same handle, so its statements threw and its page-hit and history deltas were
  * dropped on every clean stop. The ORM connection was closed by nothing at all:
  * `closeDB()` had exactly one caller, the `db:sync` CLI, so a SIGINT abandoned
@@ -84,7 +84,7 @@ export function __resetTestTeardown(): void {
  *
  * Every step is isolated: a throwing hook is reported and the rest still run.
  * A shutdown that aborts halfway loses precisely the data this sequence exists
- * to save. The whole sequence is bounded by `timeoutMs` for the same reason —
+ * to save. The whole sequence is bounded by `timeoutMs` for the same reason:
  * losing the tail of a flush beats never exiting.
  */
 export function runShutdownSequence(
@@ -94,7 +94,7 @@ export function runShutdownSequence(
   return running
 }
 
-/** Test seam — see `__setTestConfig`. Clears the once-per-process memo. */
+/** Test seam. See `__setTestConfig`. Clears the once-per-process memo. */
 export function __resetShutdownSequence(): void {
   running = null
 }
@@ -139,7 +139,7 @@ async function shutdown(): Promise<void> {
   }
 
   // Inside the step, not above it: an `await import()` that fails throws, and
-  // out here that rejection escaped the sequence entirely — taking the resource
+  // out here that rejection escaped the sequence entirely, taking the resource
   // close below with it and, in `worker.ts`, the `process.exit(0)` that follows.
   await step('plugin onShutdown', async () => {
     const { PluginHooks } = await import('@bakery-framework/core/core/plugins')

package/src/threads.ts

@@ -10,7 +10,7 @@ export const FLUSH_TIMEOUT_MS = 5000
 
 /**
  * The part of `Worker` this module needs. Narrow enough that a test can supply
- * a plain object, which is the only practical way to exercise the timeout — a
+ * a plain object, which is the only practical way to exercise the timeout: a
  * real Worker that never acknowledges means spawning a real server.
  */
 export interface FlushTarget {
@@ -20,7 +20,7 @@ export interface FlushTarget {
 }
 
 /**
- * Ask every worker to flush, and resolve when they all have — or when
+ * Ask every worker to flush, and resolve when they all have, or when
  * `timeoutMs` elapses, whichever comes first.
  *
  * `worker.terminate()` is immediate: a worker's shutdown hooks never run, so
@@ -87,7 +87,7 @@ export const RESPAWN_RESET_AFTER_MS = 60_000
  * backoff, `RESPAWN_BASE_DELAY_MS` doubling per consecutive failure up to
  * `RESPAWN_MAX_DELAY_MS`. A fixed 100ms meant a worker that died during boot
  * (bad DB URL, port conflict) re-ran initDB/setupServer ~10 times a second
- * indefinitely. Pure — delay = f(consecutiveFailures); the caller owns the
+ * indefinitely. Pure: delay = f(consecutiveFailures); the caller owns the
  * count and resets it after `RESPAWN_RESET_AFTER_MS` of survival.
  */
 export function respawnDelayMs(consecutiveFailures: number): number {
@@ -108,7 +108,7 @@ export async function handleThreadsMaster(threadCount: number) {
   if (process.platform !== 'linux' && threadCount > 1) {
     // Not just Windows: the multi-worker model needs kernel-level SO_REUSEPORT
     // load balancing, which only Linux provides. On macOS N sockets either
-    // fail to bind or never receive balanced traffic — and a bind failure
+    // fail to bind or never receive balanced traffic, and a bind failure
     // feeds the respawn loop below.
     serveLog.CLUSTER_CLAMPED({
       platform: PLATFORM_NAMES[process.platform] ?? process.platform,
@@ -138,9 +138,9 @@ export async function handleThreadsMaster(threadCount: number) {
     // getter-only the assignment threw, and a Try() swallow hid it).
     //
     // THREAD_WORKER is deliberately NOT set. It is the flag that scales caches
-    // *down* for N-way memory sharing — HandlerCache 500→50, HandlerMap
+    // *down* for N-way memory sharing: HandlerCache 500→50, HandlerMap
     // routeCache 5000→500, the tiered cache's memory tier ÷4, the SQLite page
-    // caches ~10x smaller — and a single worker that owns the whole process
+    // caches ~10x smaller, and a single worker that owns the whole process
     // would get all of that for zero benefit. Setting it here made
     // `--threads 1` strictly worse than plain `bun run serve`; leaving it
     // unset makes this path identical to plain prod.
@@ -161,7 +161,7 @@ export async function handleThreadsMaster(threadCount: number) {
   const spawnWorker = (id: number) => {
     workerState.set(id, {
       isTerminated: false,
-      // The streak survives the respawn — that is what makes it a streak.
+      // The streak survives the respawn: that is what makes it a streak.
       consecutiveFailures: workerState.get(id)?.consecutiveFailures ?? 0,
       spawnedAt: Date.now(),
     })

package/src/worker.ts

@@ -42,7 +42,7 @@ const sharedPoolBound = new Promise<void>(resolve => {
 if (typeof self !== 'undefined' && 'addEventListener' in self) {
   self.addEventListener('message', (e: any) => {
     if (e.data?.type === 'INIT_SHARED_POOL' && e.data.buffer) {
-      // Rebinds on every send on purpose — a late or repeated handover from
+      // Rebinds on every send on purpose: a late or repeated handover from
       // the master must still land; resolving the promise twice is a no-op.
       Bakery.sharedPool.bind(e.data.buffer)
       signalSharedPoolBound()
@@ -52,7 +52,7 @@ if (typeof self !== 'undefined' && 'addEventListener' in self) {
       // The cluster master asking for a flush before it calls terminate().
       // Deliberately no process.exit() here: inside a Worker thread that would
       // take the whole cluster down, master included. We flush, we acknowledge,
-      // and the master terminates us — or gives up waiting and does it anyway.
+      // and the master terminates us, or gives up waiting and does it anyway.
       void (async () => {
         Bakery.server?.stop(true)
         await runShutdownSequence()
@@ -63,9 +63,9 @@ if (typeof self !== 'undefined' && 'addEventListener' in self) {
 }
 
 try {
-  // Memoised no-op on the dev/prod entry paths, which already ran it (and
+  // Memoized no-op on the dev/prod entry paths, which already ran it (and
   // exited there if it threw). A cluster worker is spawned straight into this
-  // file and passes through neither entry, so this is its first call — and in
+  // file and passes through neither entry, so this is its first call, and in
   // PROD a present-but-broken server.config.ts must fail the boot here rather
   // than serve the built-in defaults.
   await initConfig()
@@ -74,9 +74,9 @@ try {
   process.exit(1)
 }
 
-// Skipped entirely when the ORM is not installed — the app has no database and
+// Skipped entirely when the ORM is not installed. The app has no database and
 // asked for none. Note what is *inside* the guard rather than outside it: once
-// the ORM is present, a failure to initialise is still fatal, because at that
+// the ORM is present, a failure to initialize is still fatal, because at that
 // point the app does have a database and it does not work.
 if (hasORM()) {
   try {
@@ -100,7 +100,7 @@ try {
 if (import.meta.env.THREAD_WORKER) {
   // The master posts INIT_SHARED_POOL immediately after constructing this
   // Worker, but the message lands on a later event-loop turn than an immediate
-  // Bun.serve — early requests would hit a worker-local SharedMemoryPool whose
+  // Bun.serve. Early requests would hit a worker-local SharedMemoryPool whose
   // counters and rate-limit state bind() then silently discards. So in
   // thread-worker mode only, wait for the handover before serving. Plain
   // prod/dev never set THREAD_WORKER and skip this entirely.
@@ -120,7 +120,7 @@ if (import.meta.env.THREAD_WORKER) {
 // Same resolver `startup.ts`'s banner and the dev master's URL use, so what we
 // bind and what they advertise cannot disagree. It throws on a malformed
 // `PORT` rather than handing `Bun.serve` a `NaN` it silently turns into a
-// random ephemeral port — which is how `PORT=3000x` used to produce a server
+// random ephemeral port, which is how `PORT=3000x` used to produce a server
 // on 51570 under a banner reading `http://localhost:3000/`.
 let PORT: number
 try {
@@ -146,7 +146,7 @@ try {
       const hostname = getHostname(req)
       const hostConfig = resolveHostConfig(hostname)
 
-      return hostStore.run({ config: hostConfig, hostname }, async () => {
+      return hostStore.run({ config: hostConfig, hostname, req }, async () => {
         const path = url.pathname
         req.startNs = Bun.nanoseconds()
         req.__hostname = hostname
@@ -157,7 +157,7 @@ try {
           const key = rateLimitKey(rl, req, hostname)
           const slot = rateLimitSlot(key)
           if (!Bakery.sharedPool.consumeToken(slot, rl.max, rl.refill)) {
-            // Sampled — availability under flood: stdout is effectively
+            // Sampled: availability under flood: stdout is effectively
             // synchronous on Windows, so a line per rejection replays the
             // flood the limiter just absorbed as a logging flood.
             const suppressed = sampleRateLimitLog(key)
@@ -208,7 +208,7 @@ try {
       serveLog.UNHANDLED_ERR({ error: errorMsg(error) })
       const hostname = req ? getHostname(req) : ''
       const hostConfig = resolveHostConfig(hostname)
-      return hostStore.run({ config: hostConfig, hostname }, async () => {
+      return hostStore.run({ config: hostConfig, hostname, req }, async () => {
         return await handleRequestError('/', req, error)
       })
     },
@@ -221,7 +221,7 @@ try {
 if (isDevWorker) {
   // One `.catch` on the whole chain, not one nested inside the `.then`. The
   // nested form covered `startCompileService` rejecting but left the dynamic
-  // `import()` itself unhandled — so a compiler module that failed to load
+  // `import()` itself unhandled, so a compiler module that failed to load
   // produced an unhandled rejection rather than the WATCHER_ERR line that
   // exists to report exactly that.
   import('@bakery-framework/core/compiler')
@@ -241,7 +241,7 @@ async function handleShutdown(signal: string) {
 
   Bakery.server?.stop(true)
 
-  // config.onShutdown, framework hooks, plugins, then resource close — see
+  // config.onShutdown, framework hooks, plugins, then resource close. See
   // shutdown.ts for why that order. It used to run only the middle two, so an
   // application's `onShutdown` was declared, defaulted to a no-op, and never
   // called. The sequence carries its own deadline.
@@ -252,7 +252,7 @@ async function handleShutdown(signal: string) {
  * `process.exit(0)` lives here, in a `finally`, because `handleShutdown` is
  * async and the signal handler cannot await it: registered directly, its
  * promise was neither awaited nor caught, so a rejection anywhere in teardown
- * became an unhandled rejection *and* skipped the exit — the process kept
+ * became an unhandled rejection *and* skipped the exit, the process kept
  * running with its listener stopped, answering nothing.
  */
 function onSignal(signal: string): void {