@@ -159,18 +159,21 @@ export const CloseStaleTasksJob = defineJob({
     `,
     capabilities: ['api.read', 'api.write', 'log'],
   },
-  handler: 'closeStaleTasks', // deprecated — kept until the runtime runs job bodies (see below)
+  handler: 'closeStaleTasks', // deprecated and optional — `body` wins when both are present
   timeoutMs: 120000,
 });
 ```
 
-<Callout type="warn">
-  **The runtime does not run a job `body` yet.** Scheduling a job's body is a
-  separate change that has not landed: until it does, a job is scheduled through
-  its `handler`, and a job with a `body` and no `handler` is skipped at boot with
-  a `warn`. `os validate` and `os build` say so wherever a `body` is set. Keep
-  `handler` beside `body` for now; the `body` is validated today, so it is ready
-  the day the runtime starts honouring it.
+<Callout>
+  **Every door runs a job `body`.** The boot (a config, or `os start --artifact`)
+  and `os package install` (on install, and again on every restart) schedule a
+  job's `body` through the same binder. A `handler` is code: it travels only in the
+  artifact's runtime module, so it runs only on a boot that loads that module (a
+  config, or `os start --artifact`). `os package install` therefore refuses a
+  package whose enabled job has no `body`, with `422 VALIDATION_ERROR` and the
+  remedy: give the job a `body`, or boot it with `os start --artifact`.
+  Uninstalling a package stops its scheduled jobs at once, and a reinstall whose
+  new version drops a job stops that job.
 </Callout>
 
 What running in the sandbox means for the code in `source`:
 
@@ -58,7 +58,7 @@ const result = CronScheduleSchema.parse(data);
 | **description** | `string` | optional | Job description / purpose |
 | **schedule** | `{ type: 'cron'; expression: string \| object; timezone?: string } \| { type: 'interval'; intervalMs: integer } \| { type: 'once'; at: string }` | ✅ | Job schedule configuration |
 | **handler** | `string` | optional | Handler function name (must match a key in `defineStack({ functions })`) — DEPRECATED, prefer `body`. When both are present `body` wins; a job must declare one of the two. |
-| **body** | `{ language: 'js'; source: string; capabilities?: Enum<'api.read' \| 'api.write' \| 'api.transaction' \| 'crypto.uuid' \| 'log'>[]; timeoutMs?: integer; … }` | optional | Job body — a sandboxed JS (L2) body, the same shape hooks and actions use; an expression (L1) body is refused, because a job runs for its effects and an expression has none. Preferred over `handler`: when both are present `body` wins. It runs in the QuickJS sandbox with no module scope (no imports, no helpers or constants from the surrounding file): it reaches data only through `ctx.api` under its declared `capabilities` (`api.read` / `api.write` / `api.transaction`) and logs through `ctx.log` (`log`); the in-process handler context (`ql`, `logger`, `bundle`) does not exist there. Its time limit is the job's `timeoutMs` (see there): long-running work declares a `timeoutMs` that covers it, or splits into bounded runs that each finish within it. The runtime binder that schedules job bodies has not landed yet: until it does a job runs through `handler`, so keep `handler` beside `body`. |
+| **body** | `{ language: 'js'; source: string; capabilities?: Enum<'api.read' \| 'api.write' \| 'api.transaction' \| 'crypto.uuid' \| 'log'>[]; timeoutMs?: integer; … }` | optional | Job body — a sandboxed JS (L2) body, the same shape hooks and actions use; an expression (L1) body is refused, because a job runs for its effects and an expression has none. Preferred over `handler`: when both are present `body` wins. It runs in the QuickJS sandbox with no module scope (no imports, no helpers or constants from the surrounding file): it reaches data only through `ctx.api` under its declared `capabilities` (`api.read` / `api.write` / `api.transaction`) and logs through `ctx.log` (`log`); the in-process handler context (`ql`, `logger`, `bundle`) does not exist there. Its time limit is the job's `timeoutMs` (see there): long-running work declares a `timeoutMs` that covers it, or splits into bounded runs that each finish within it. Every door that brings an artifact in schedules a job's `body` — the boot, and `os package install` on install and on every restart — while a `handler` is code that travels only in the artifact's runtime module and runs only on a boot that loads it (a config, or `os start --artifact`); `os package install` therefore refuses an enabled job with no `body`. |
 | **retryPolicy** | `{ maxRetries?: integer; backoffMs?: integer; backoffMultiplier?: number; maxRetryDelayMs?: integer; … }` | optional | Retry policy: failed runs (including timeouts) are retried with exponential backoff (delay = min(backoffMs * backoffMultiplier^(retry-1), maxRetryDelayMs), optionally jittered) up to maxRetries retries after the initial attempt. Omit the block for a single attempt; declaring it without `maxRetries` also means no retry since 17.0.0 — state a count to opt in. |
 | **timeoutMs** | `integer` | optional | Per-attempt time limit in milliseconds; an over-limit run is recorded with execution status "timeout". A `handler` run is abandoned, not forcibly cancelled. For a job with a `body` this is the ONE time limit: one attempt is one sandbox invocation, the runtime bounds that invocation by this value, and the body shape's own `timeoutMs` (capped at 30000 for hooks and actions) is refused on a job — so this key, which has no such cap, is where long-running work states how long it needs. Omit for no per-attempt limit; a `body` run is then still bounded by the sandbox's own default invocation limits. |
 | **timeout** | `never` | optional | [REMOVED] `job.timeout` was removed in @objectstack/spec 17 — its unit (milliseconds) lived only in the description while the sibling `retryPolicy.backoffMs` spells its own, so the same number read as two conventions on one surface. Rename the key to `timeoutMs`; the value (milliseconds) is unchanged. Run `os migrate meta --from 17` to list the mechanical edits for existing sources; apply them by hand. |
 
@@ -267,7 +267,7 @@ export const JobSchema = lazySchema(() => strictObject({
       + 'Preferred over `handler`: when both are present `body` wins. '
       + 'It runs in the QuickJS sandbox with no module scope (no imports, no helpers or constants from the surrounding file): it reaches data only through `ctx.api` under its declared `capabilities` (`api.read` / `api.write` / `api.transaction`) and logs through `ctx.log` (`log`); the in-process handler context (`ql`, `logger`, `bundle`) does not exist there. '
       + "Its time limit is the job's `timeoutMs` (see there): long-running work declares a `timeoutMs` that covers it, or splits into bounded runs that each finish within it. "
-      + 'The runtime binder that schedules job bodies has not landed yet: until it does a job runs through `handler`, so keep `handler` beside `body`.',
+      + "Every door that brings an artifact in schedules a job's `body` — the boot, and `os package install` on install and on every restart — while a `handler` is code that travels only in the artifact's runtime module and runs only on a boot that loads it (a config, or `os start --artifact`); `os package install` therefore refuses an enabled job with no `body`.",
   ),
   retryPolicy: RetryPolicySchema.optional().describe('Retry policy: failed runs (including timeouts) are retried with exponential backoff (delay = min(backoffMs * backoffMultiplier^(retry-1), maxRetryDelayMs), optionally jittered) up to maxRetries retries after the initial attempt. Omit the block for a single attempt; declaring it without `maxRetries` also means no retry since 17.0.0 — state a count to opt in.'),
   // Renamed from `timeout` (#14478): the unit (milliseconds) lived only in the
@@ -312,8 +312,9 @@ export type JobParsed = z.infer<typeof JobSchema>;
  *     source: "const open = await ctx.api.object('task').find({ where: { status: 'open' } }); ctx.log.info('open tasks', { count: open.length });",
  *     capabilities: ['api.read', 'log'],
  *   },
- *   // Deprecated, kept beside `body` until the runtime binder runs job bodies:
- *   // must be registered in defineStack({ functions: { syncMetadata: () => ... } })
+ *   // Deprecated and optional beside `body`, which wins when both are present. It
+ *   // names a defineStack({ functions }) entry, which only a boot that loads the
+ *   // artifact's runtime module (a config, or `os start --artifact`) can run.
  *   handler: 'syncMetadata',
  * });
  * ```