@warlock.js/core 5.30.0 → 5.32.0

package/skills/test-http/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-http
-description: 'Integration tests against a real HTTP server — `startHttpTestServer()` boots one shared server in globalSetup, then `testGet` / `testPost` / `expectJson` make typed requests against it. Triggers: `startHttpTestServer`, `startHttpTestServer({ port })`, `stopHttpTestServer`, `testGet`, `testPost`, `testPut`, `testPatch`, `testDelete`, `expectJson`, `getTestServerUrl`, `testRequest`, `PortInUseError`, `assertPortIsAvailable`, `isPortAvailable`; "integration-test a controller", "end-to-end HTTP test", "globalSetup HTTP server", "assert status and body shape", "test server port already in use", "EADDRINUSE while running tests", "run tests while the dev server is up"; typical import `import { testGet, testPost, expectJson } from "@warlock.js/core/tests"`. Skip: pure unit tests — the `test-service` topic; controller shape — the `create-controller` topic; competing libs `supertest`, `light-my-request`, `nock`.'
+description: 'Integration tests against a real HTTP server — `startHttpTestServer()` boots one shared server in globalSetup, then `testGet` / `testPost` / `expectJson` make typed requests against it. Triggers: `startHttpTestServer`, `startHttpTestServer({ port })`, `startHttpTestServer({ port: 0 })`, `stopHttpTestServer`, `createTestHttpServer`, `TestHttpServer`, `createTestRequestClient`, `snapshotResponse`, `actingAs`, `AuthenticatedTestClient`, `testGet`, `testPost`, `testPut`, `testPatch`, `testDelete`, `expectJson`, `getTestServerUrl`, `testRequest`, `PortInUseError`, `assertPortIsAvailable`, `isPortAvailable`; "integration-test a controller", "end-to-end HTTP test", "globalSetup HTTP server", "assert status and body shape", "test server port already in use", "EADDRINUSE while running tests", "run tests while the dev server is up", "ephemeral test port", "test with the real Fastify plugins", "assert mail sent by a request", "response snapshot"; typical import `import { testGet, testPost, expectJson } from "@warlock.js/core/tests"`. Skip: pure unit tests — the `test-service` topic; controller shape — the `create-controller` topic; competing libs `supertest`, `light-my-request`, `nock`.'
 ---
 
 # Warlock — HTTP integration tests
@@ -38,6 +38,52 @@ describe("Users API", () => {
 
 No `beforeAll`, no manual server start — the project's `src/test-global-setup.ts` brought the HTTP server up once before any test ran.
 
+## Signed-in requests — `actingAs(user)`
+
+```ts
+import type { Auth } from "@warlock.js/auth";
+import { actingAs, expectJson } from "@warlock.js/core/tests";
+import { expect } from "vitest";
+
+export async function expectNoUnreadNotifications(user: Auth) {
+  const client = await actingAs(user);
+  try {
+    const body = await expectJson<{ count: number }>(
+      await client.get("/notifications/unread-count"),
+    );
+    expect(body.count).toBe(0);
+  } finally {
+    await client.dispose();
+  }
+}
+```
+
+`actingAs()` requires `NODE_ENV="test"` before issuing any credentials.
+Cookie-only auth middleware needs the app's login route rather than this Bearer client.
+
+The helper calls the user's real `generateAccessToken()` and sends its persisted
+credential as a Bearer header. Auth middleware, account policy and token expiry
+still apply. It does not test the app's login route or create a user for you.
+Use your login route directly when testing credentials/session cookies.
+
+Each client owns its identity, so parallel users and anonymous `testGet()` calls
+remain separate. Extra headers/signals use the normal helper options; a supplied
+Authorization header is replaced by the bound user's token. `client.dispose()`
+revokes only that token. Fixture owners clean up their own users and rows.
+
+## Generated notification specs
+
+Install test support before notifications (`warlock add test`, then
+`warlock add notifications`) to emit a shared fixture and signed-in `.spec.ts`
+cases for list/unread-count/mark-read/mark-all. They use the configured
+`auth.userType.user` model with `actingAs()` and a second recipient to check
+isolation. Run against a migrated test database; customize required user fields
+in `notifications/tests/notifications.fixture.ts`. Cleanup revokes the fixture's
+tokens and deletes only its rows/users.
+
+Existing Vitest configurations must include both test extensions:
+`include: ["src/app/**/*.{test,spec}.ts"]`.
+
 ## The bootstrap — `startHttpTestServer` / `stopHttpTestServer`
 
 ```ts
@@ -90,23 +136,75 @@ startHttpTestServer({ port: 2032 }).
 
 This runs whether or not you passed a port, so a collision never reaches you as a bare `EADDRINUSE` from inside Fastify. The failure is a `PortInUseError` carrying `port` and `host`. The same check is available on its own — `assertPortIsAvailable(port, host)` throws it, `isPortAvailable(port, host)` returns a boolean.
 
-### Port `0` is refused
-
-`port: 0` — "let the OS pick one" — is not supported, and says so rather than half-working:
+### Port `0` — let the OS pick
 
+```ts
+await startHttpTestServer({ port: 0 });
 ```
-startHttpTestServer() cannot run on port 0. Pass an explicit port — e.g.
-startHttpTestServer({ port: 3999 }) — or set `http.port` in your config. Test workers
-are separate processes that resolve the server's URL from the port published at
-startup, and an OS-assigned port is not knowable to them.
-```
 
-The reason is the worker handoff described above: the port the OS assigns is never recorded anywhere the workers can read, so `getTestServerUrl()` would resolve `0` and send every request to `http://host:0`.
+`port: 0` binds whatever free port the OS hands out — what `warlock add test` generates. There is nothing to preflight; once the HTTP connector has bound, the port it actually took is published as `WARLOCK_TEST_SERVER_PORT`, so `testGet()`, `actingAs()` and friends follow it. If the connector bound nothing (no `src/config/http.ts`, or a worker-only role), startup fails saying so instead of publishing `0`. A negative port is refused.
+
+⚠ **Changed in 5.31.0.** `port: 0` used to be refused, because the bound port was not recorded anywhere the workers could read. `HttpConnector.start()` now records the port `listen()` returned, and that is what gets published.
 
 ### If startup fails, nothing is left behind
 
 `startHttpTestServer()` owns the connectors it starts. A failure part-way through — a bad config, a connector that won't boot — tears down whatever came up, withdraws the published port, and **rethrows the original error**; a failure during that cleanup is logged but never replaces the cause. `stopHttpTestServer()` withdraws the port and resets its state even when the shutdown itself throws, and still surfaces that failure.
 
+## In the worker, with the production plugins — `createTestHttpServer()`
+
+The shared server runs in Vitest's main process, so the test fakes in a worker never see what a request did there. `createTestHttpServer()` serves requests inside the worker instead, built the way production builds it: `startHttpServer()`, every plugin `registerHttpPlugins()` registers (rate limit with its cache store, CORS, multipart, cookies), the router's real route registration, an OS-assigned port.
+
+```ts
+import { createTestHttpServer, mailFake, type TestHttpServer } from "@warlock.js/core/tests";
+import { afterEach, expect, it } from "vitest";
+
+let app: TestHttpServer | undefined;
+
+afterEach(async () => {
+  await app?.close();
+});
+
+it("answers through the real plugins and lets the fakes see the handler", async () => {
+  app = await createTestHttpServer({
+    routes: (router) =>
+      router.post("/echo", ({ request, response }) =>
+        response.success({ name: request.input("name") }),
+      ),
+  });
+
+  const response = await app.post("/echo", { name: "Ada" });
+
+  expect(response.status).toBe(200);
+  mailFake.assertNothingSent();
+});
+```
+
+- `loadAppModules: true` (with `importModule: (file) => import(file)`, as `setupTest()` takes it) serves every app route; modules load once per process. Needs `setupTest()` to have run in the worker.
+- `routes: (router) => …` registers routes for this server only; `close()` removes them.
+- It returns `url`, `port`, `server` (Fastify, for `inject()`), the request helpers, `actingAs(user)` bound to it, and `close()`.
+- `createTestRequestClient(baseUrl)` gives the same helpers bound to any URL.
+
+## Response snapshots — `snapshotResponse()`
+
+```ts
+import { snapshotResponse, testPost } from "@warlock.js/core/tests";
+import { expect, it } from "vitest";
+
+it("creates a post", async () => {
+  const response = await testPost("/posts", { title: "Hello" });
+
+  expect(
+    await snapshotResponse(response, { redact: ["post.id", "post.createdAt"] }),
+  ).toMatchSnapshot();
+});
+```
+
+The snapshot is `{ status, contentType, body }`; redacted paths read `"[redacted]"`, and `*` matches any key or index (`"posts.*.id"`). It consumes the body.
+
+## Fakes in the server process
+
+`startHttpTestServer()` installs the test fakes too (mail, queue, cache, storage, clock, ids — see the `test-fakes` topic), honouring `tests.fakes` and its own `fakes` option. They record in the main process, so assert on request side effects with `createTestHttpServer()`; the storage fake's temp root is shared with the workers (`WARLOCK_TEST_STORAGE_ROOT`).
+
 ## Project wiring — `src/test-global-setup.ts` + `vite.config.ts`
 
 ```ts title="src/test-global-setup.ts"
@@ -117,7 +215,7 @@ The reason is the worker handoff described above: the port the OS assigns is nev
 import { startHttpTestServer, stopHttpTestServer } from "@warlock.js/core/tests";
 
 export async function setup() {
-  await startHttpTestServer();
+  await startHttpTestServer({ port: 0 });
 }
 
 export async function teardown() {
@@ -137,7 +235,7 @@ export default defineConfig({
     setupFiles: ["./src/test-setup.ts"], // ← setupTest + afterAll(teardownTest), per test file
     environment: "node",
     globals: false,
-    include: ["src/app/**/*.test.ts"],
+    include: ["src/app/**/*.{test,spec}.ts"],
   },
 });
 ```
@@ -204,13 +302,16 @@ All accept a relative path (leading `/` optional) and a standard `RequestInit`.
 ```ts
 import { expectJson, parseJsonResponse } from "@warlock.js/core/tests";
 
+type MyShape = { id: number; name: string };
+declare const response: Response; // from testGet / testPost / fetch
+
 // Parse-only
-const body = await parseJsonResponse<MyShape>(response);
+const parsed = await parseJsonResponse<MyShape>(response);
 
 // Assert status + parse in one call
-const body = await expectJson<MyShape>(response); // expects 200
-const body = await expectJson<MyShape>(response, 201); // expects 201
-const body = await expectJson<MyShape>(response, 404); // expects 404 (testing error paths)
+const ok = await expectJson<MyShape>(response); // expects 200
+const created = await expectJson<MyShape>(response, 201); // expects 201
+const missing = await expectJson<MyShape>(response, 404); // expects 404 (testing error paths)
 ```
 
 `expectJson` throws with the actual status + response body when the assertion fails — no chasing "got 500" messages without context.
@@ -263,10 +364,10 @@ import { User } from "src/app/users/models/user";
 
 it("GET /me returns the current user", async () => {
   const user = await User.create({ email: "auth@e.com", password: "secret" });
-  const { accessToken } = await authService.generateTokens(user);
+  const { accessToken } = await authService.createTokenPair(user);
 
   const response = await testGet("/me", {
-    headers: { Authorization: `Bearer ${accessToken}` },
+    headers: { Authorization: `Bearer ${accessToken.token}` },
   });
 
   const { user: me } = await expectJson<{ user: { email: string } }>(response);
@@ -290,8 +391,8 @@ export async function createUserAndToken(overrides: Partial<{ email: string }> =
     password: "test-secret",
   });
 
-  const { accessToken } = await authService.generateTokens(user);
-  return { user, accessToken, authHeader: { Authorization: `Bearer ${accessToken}` } };
+  const { accessToken } = await authService.createTokenPair(user);
+  return { user, accessToken, authHeader: { Authorization: `Bearer ${accessToken.token}` } };
 }
 ```
 
@@ -342,7 +443,7 @@ This is fine for normal test flow. It bites when you're inside a transaction the
 ## Gotchas
 
 - **`globalSetup` must export `setup` and `teardown`.** Vitest reads them by name. A typo in the export gets you a confusing "server not running" error on the first `testGet` call.
-- **Port conflicts.** If `http.port` matches your running dev server, the preflight fails with a `PortInUseError` naming the port. Either stop the dev server or pass a free one: `startHttpTestServer({ port: 3999 })`.
+- **Port conflicts.** If `http.port` matches your running dev server, the preflight fails with a `PortInUseError` naming the port. Pass `startHttpTestServer({ port: 0 })` to let the OS pick, or a fixed free one: `startHttpTestServer({ port: 3999 })`.
 - **Auth tokens need a real user.** Generating a JWT with a non-existent `user_id` works — but the auth middleware's user-loading step will reject the request with 401 because it can't find the user in the DB.
 - **`expectJson` parses the body once.** If you call it twice on the same response, the second call gets an already-consumed stream error. Capture the result.
 - **The HTTP server's connection is NOT torn down between test files.** Data persists across files within a single `vitest` run. Either truncate in `afterEach` / `afterAll`, or design your tests to be order-independent.
@@ -351,6 +452,9 @@ This is fine for normal test flow. It bites when you're inside a transaction the
 ## See also
 
 - The `test-service` topic — pure unit tests against services/repositories/models (no HTTP).
+- The `test-fakes` topic — mail, queue, cache, storage, clock and ids fakes and their assertions.
+- The `model-factories` topic — `defineFactory()` for deterministic fixtures.
+- The `make-endpoint` topic — `warlock make endpoint` writes an endpoint with its HTTP test.
 - The `create-controller` topic — the controller shape your HTTP tests are exercising.
 - The `warlock-conventions` topic — module layout, where `tests/*.test.ts` files live.
 - The `write-cli-command` topic — `warlock add test` scaffolds both global + worker setup files.

package/skills/test-service/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-service
-description: 'Pure unit tests against services, repositories, models, and use-cases — `setupTest({ connectors })` bootstraps the framework with its own DB/cache connections so you can call your code directly, and `teardownTest()` closes it. Triggers: `setupTest`, `teardownTest`, `src/test-setup.ts`, `tests.connectors`, `tests.setupTimeout`, `Application.setEnvironment`; "unit-test a service", "test a repository query", "vitest setupFiles", "skip connectors for pure-logic tests"; typical import `import { setupTest, teardownTest } from "@warlock.js/core/tests"`. Skip: HTTP integration — the `test-http` topic; warlock add test scaffold — the `write-cli-command` topic; competing tooling: jest direct, `supertest`, `nock`.'
+description: 'Pure unit tests against services, repositories, models, and use-cases — `setupTest({ connectors })` bootstraps the framework with its own DB/cache connections so you can call your code directly, and `teardownTest()` closes it. Triggers: `setupTest`, `teardownTest`, `setupTest({ fakes })`, `tests.fakes`, `src/test-setup.ts`, `tests.connectors`, `tests.setupTimeout`, `Application.setEnvironment`, `clock`, `ids`, `warlock test --changed`; "unit-test a service", "test a repository query", "vitest setupFiles", "skip connectors for pure-logic tests", "run only the tests my change affects", "deterministic time in a test"; typical import `import { setupTest, teardownTest } from "@warlock.js/core/tests"`. Skip: HTTP integration — the `test-http` topic; warlock add test scaffold — the `write-cli-command` topic; competing tooling: jest direct, `supertest`, `nock`.'
 ---
 
 # Warlock — test a service
@@ -315,6 +315,38 @@ afterAll(async () => {
 
 **Option 2 is usually right, and option 1 is easy to get wrong.** Tearing down and re-bootstrapping costs a full framework startup — twice, once for your file and once for the next — to avoid a DB connection you were never going to use. **Reach for option 1 only when a connector's mere presence breaks the thing you're testing**, not to save setup time.
 
+## Fakes are on — `setupTest({ fakes })`
+
+Once its connectors are up, `setupTest()` installs the test fakes — mail, queue, cache, storage, clock and ids — and `teardownTest()` restores them first, while the real drivers are still connected. A service under test therefore sends no mail, pushes no job to Redis, uploads nothing and reads a frozen `clock`:
+
+```ts
+// with: import { clock } from "@warlock.js/core";
+//       import { clockFake, mailFake } from "@warlock.js/core/tests";
+//       plus your service (issueResetToken, isResetTokenValid)
+it("expires a reset token after 15 minutes", async () => {
+  const token = await issueResetToken("ada@example.test"); // expiresAt = clock.timestamp() + 15 min
+
+  clockFake.travel(16 * 60_000);
+
+  expect(await isResetTokenValid(token)).toBe(false);
+  expect(clock.now().toISOString()).toBe("2026-01-01T00:16:00.000Z");
+  mailFake.assertSent({ to: "ada@example.test" });
+});
+```
+
+Precedence is `explicit option > tests.fakes config > true`. Opt out in `src/config/tests.ts` (`fakes: false`, or `fakes: { cache: false }`) or per call (`setupTest({ importModule, fakes: false })`). The full assertion API is the `test-fakes` topic; deterministic fixtures are `model-factories`.
+
+## Running only what changed — `warlock test`
+
+```bash
+warlock test --changed                # tests affected by uncommitted changes
+warlock test --changed --since main   # ... by changes since main
+warlock test --related src/app/posts/services/create-post.service.ts
+warlock test --json                   # Vitest's JSON report on stdout
+```
+
+It runs the project's own Vitest with `NODE_ENV=test`; a change that affects no test passes (`--passWithNoTests`).
+
 ## Lifecycle and repeated calls
 
 `setupTest` / `teardownTest` are a pair. **The harness that calls one owns calling the other in the same context.**
@@ -379,6 +411,12 @@ In both cases the guard's scope matches the resource's scope, which is the point
 
 ## Gotchas
 
+When a unit test copies TypeScript source into a temporary directory for a fresh
+Node process, preserve the source package's module mode. ESM fixtures need a
+`package.json` with `"type": "module"`; otherwise `tsx` can load the copy as
+CommonJS and named exports fail before the behavior under test runs. Assert the
+child process exit status with its captured stderr before checking stdout.
+
 - **`setupTest` runs per test file, not per worker** — every version of this skill through 4.13.0 said otherwise. **You pay one framework bootstrap per test file**, which is what 4.13.0 already cost; the difference is that it is now a chosen lifetime rather than a side effect of a module flag resetting.
 - ⛔ **Never delete the `afterAll(teardownTest)` from your setup file.** Without it nothing closes what `setupTest` opened, and the connectors outlive the file that started them.
 - ⛔ **You can't swap the connector set by calling `setupTest` again — it rejects now.** Through 4.13.0 the second call was silently ignored. Tear down first, or don't call it.
@@ -391,6 +429,8 @@ In both cases the guard's scope matches the resource's scope, which is the point
 
 ## See also
 
+- The `test-fakes` topic — every fake and its assertions.
+- The `model-factories` topic — `defineFactory()`.
 - The `test-http` topic — integration tests via the real HTTP server (`startHttpTestServer` + `testGet` / `testPost` / `expectJson`).
 - The `warlock-conventions` topic — where tests live in a module (`tests/*.test.ts`).
 - The `write-cli-command` topic — `warlock add test` for the initial scaffold.

package/skills/update-packages/SKILL.md

@@ -7,6 +7,17 @@ description: 'Keep a project current with `warlock update` — bump every `@warl
 
 `warlock update` upgrades a project's Warlock packages in one step, and `warlock dev` tells you when an upgrade is available. Because the whole `@warlock.js/*` family ships in **lockstep** — every package shares one version — keeping them in sync is the normal case, and this command does exactly that.
 
+## `warlock update` vs `warlock upgrade`
+
+`warlock update` moves the packages to the latest versions and nothing else.
+When a release has breaking changes, use
+`warlock upgrade --from <current> --to <version>` (`--dry-run` first), e.g.
+`warlock upgrade --from 5.30 --to 5.31.0`: it moves the packages to that release
+AND applies the code edits its breaking changes need, listing the rest with
+`file:line`. Pass `--from`: the command ships with the new release, so once it
+is installed the detected `@warlock.js/core` is already the target. See the
+`upgrade-from-5-29` topic.
+
 ## `warlock update`
 
 ```bash
@@ -24,10 +35,10 @@ warlock update --check          # same, but exit 1 when behind — a CI gate
 
 `--check` is the CI form — its exit code carries the answer:
 
-| Exit | Meaning                                                              |
-| ---- | -------------------------------------------------------------------- |
-| `0`  | Every `@warlock.js/*` package is current.                            |
-| `1`  | At least one is behind (or the registry could not be reached).       |
+| Exit | Meaning                                                        |
+| ---- | -------------------------------------------------------------- |
+| `0`  | Every `@warlock.js/*` package is current.                      |
+| `1`  | At least one is behind (or the registry could not be reached). |
 
 Both flags imply a dry run, so neither ever writes to `package.json`.
 
@@ -39,19 +50,19 @@ What it does, in order:
 4. Rewrites each matching spec, **preserving the range operator**: `^4.2.0` → `^4.3.0`, `~4.2.0` → `~4.3.0`, an exact `4.2.0` → `4.3.0`. Specs that are not a plain semver — `workspace:*`, `*`, `latest`, git/file URLs — are left exactly as written, and any package already at or ahead of latest is skipped.
 5. Runs the project's install to reconcile `node_modules`, chosen by the lockfile present. Skipped with `--no-install`.
 
-| Lockfile                        | Install         | Add (`warlock add`) |
-| ------------------------------- | --------------- | ------------------- |
-| `bun.lock` / `bun.lockb`        | `bun install`   | `bun add`           |
-| `package-lock.json`             | `npm install`   | `npm install`       |
-| `yarn.lock`                     | `yarn install`  | `yarn add`          |
-| `pnpm-lock.yaml`                | `pnpm install`  | `pnpm add`          |
-| *none*                          | `npm install`   | `npm install`       |
+| Lockfile                 | Install        | Add (`warlock add`) |
+| ------------------------ | -------------- | ------------------- |
+| `bun.lock` / `bun.lockb` | `bun install`  | `bun add`           |
+| `package-lock.json`      | `npm install`  | `npm install`       |
+| `yarn.lock`              | `yarn install` | `yarn add`          |
+| `pnpm-lock.yaml`         | `pnpm install` | `pnpm add`          |
+| _none_                   | `npm install`  | `npm install`       |
 
 Bun is checked **first**: a Bun project may also carry a `yarn.lock` (Bun writes one for tooling compatibility), and matching yarn there would run the wrong installer against the wrong lockfile. `warlock update` and `warlock add` share this detection, so they can never disagree.
 
 Re-running on an already-current project is a no-op: nothing resolves as newer, so it prints "All @warlock.js packages are already up to date" and exits without writing or installing.
 
-**Offline is not "up to date".** If *every* registry lookup fails, the command says so and changes nothing:
+**Offline is not "up to date".** If _every_ registry lookup fails, the command says so and changes nothing:
 
 ```
 ⚠ Could not reach the npm registry — no versions were changed. Check your connection and try again.
@@ -71,7 +82,7 @@ On start, `warlock dev` checks npm for a newer `@warlock.js/core` and prints a o
 
 Core's version stands in for the whole family (lockstep), so a single lookup is enough. The check is **best-effort and non-blocking** — it runs fire-and-forget after the server is ready, never delays or breaks startup, and stays silent on any failure (offline, registry down, timeout). Its abort budget is 5s, much shorter than the `warlock update` command's, so a hanging network leaves nothing behind.
 
-**The answer is cached for 24 hours** in `.warlock/update-check.json`, so a normal day of dev-server restarts costs one registry lookup rather than one per boot. Three deliberate details: a **failed** lookup is never cached (one flaky moment must not silence the notice for a day), an entry stamped in the *future* is ignored (a clock that moves backwards would otherwise pin the cache as fresh forever), and the entry is **dropped** once `u` actually applies an update, so the next boot compares against the version you just installed.
+**The answer is cached for 24 hours** in `.warlock/update-check.json`, so a normal day of dev-server restarts costs one registry lookup rather than one per boot. Three deliberate details: a **failed** lookup is never cached (one flaky moment must not silence the notice for a day), an entry stamped in the _future_ is ignored (a clock that moves backwards would otherwise pin the cache as fresh forever), and the entry is **dropped** once `u` actually applies an update, so the next boot compares against the version you just installed.
 
 ### The `u` shortcut
 
@@ -83,11 +94,11 @@ Pressing `u` on that notice runs the whole upgrade without leaving the dev serve
 
 What happens when it doesn't go to plan:
 
-| Situation                     | Result                                                                       |
-| ----------------------------- | ----------------------------------------------------------------------------- |
-| Registry unreachable          | Nothing changes, the server keeps serving, and `u` is re-armed for a retry.   |
+| Situation                     | Result                                                                                                   |
+| ----------------------------- | -------------------------------------------------------------------------------------------------------- |
+| Registry unreachable          | Nothing changes, the server keeps serving, and `u` is re-armed for a retry.                              |
 | Install failed                | `package.json` keeps the new versions; `u` is **not** re-armed — finish the install and restart by hand. |
-| Restart could not be launched | The notice tells you to restart manually.                                     |
+| Restart could not be launched | The notice tells you to restart manually.                                                                |
 
 The shortcut is only offered when stdin is an interactive TTY. When it isn't (CI, piped stdin, a process supervisor), the notice falls back to the `Run npx warlock update` line instead — it never silently does nothing.
 
@@ -124,7 +135,7 @@ Two small zero-dependency utilities back the tooling and are exported from `@war
 - **Non-semver specs are intentionally skipped.** A `workspace:*` or `*` dependency stays as written; `update` will not pin it to a concrete version.
 - **The notice never blocks dev.** If npm is unreachable, `warlock dev` behaves exactly as before — no delay, no error, no notice, and no `u` shortcut.
 - **`u` is not offered without a TTY.** Don't expect it in CI logs or piped output; the notice prints the command instead.
-- **`warlock update` is not `warlock add`.** `add` installs a *new* feature package and runs its setup hooks; `update` only bumps the versions of packages you already depend on.
+- **`warlock update` is not `warlock add`.** `add` installs a _new_ feature package and runs its setup hooks; `update` only bumps the versions of packages you already depend on.
 
 ## See also