docs: update changelog for latest runtime changes

Author: RomainLanz

.changelog/adapter-aware-workers-and-schedules.md

@@ -0,0 +1,68 @@
+# Adapter-Aware Workers and Schedules
+
+## New Features
+
+### Select an Adapter per Worker
+
+Workers can now listen on a specific registered Adapter with `worker.adapter`. When omitted, the
+worker continues to use the queue manager's default Adapter.
+
+```typescript
+const config = {
+  default: 'redis',
+  adapters: {
+    redis: redis(redisConfig),
+    database: knex(databaseConfig),
+  },
+  worker: {
+    adapter: 'database',
+    concurrency: 5,
+  },
+}
+
+const worker = new Worker(config)
+await worker.start(['default', 'emails'])
+```
+
+This makes it possible to run separate workers for queues stored by different Adapters.
+
+### Store and Access Schedules on a Specific Adapter
+
+Schedules can now select their owning Adapter with `.with()`:
+
+```typescript
+await CleanupJob.schedule({ days: 30 }).id('daily-cleanup').with('redis').cron('0 0 * * *')
+```
+
+`Schedule.find()` and `Schedule.list()` accept an Adapter selector when accessing schedules outside
+the default Adapter:
+
+```typescript
+const schedule = await Schedule.find('daily-cleanup', { adapter: 'redis' })
+const schedules = await Schedule.list({ status: 'active' }, { adapter: 'redis' })
+```
+
+A returned `Schedule` retains the selected Adapter for subsequent `pause()`, `resume()`, `delete()`,
+and `trigger()` calls. Jobs dispatched by a schedule stay on the Adapter that owns that schedule.
+
+### Identify Jobs Dispatched by a Schedule
+
+Scheduled jobs now include their originating schedule ID in `JobData.scheduleId`. Jobs can access it
+while executing through `this.context.scheduleId`:
+
+```typescript
+async execute() {
+  console.log(this.context.scheduleId)
+}
+```
+
+The value is `undefined` for jobs that were not dispatched by a schedule.
+
+## Upgrade Notes
+
+Start a Worker for every Adapter that owns schedules. A Worker only claims schedules and jobs from
+its configured Adapter.
+
+When a schedule does not call `.with()`, its Adapter is resolved from the job's `adapter` option,
+then from the Adapter configured for the job's queue, and finally from the queue manager default.
+An explicit `.with()` always takes precedence.

.changelog/consistent-job-runtime.md

@@ -0,0 +1,30 @@
+# Consistent Job Dispatch and Execution
+
+## Improvements
+
+All job dispatch paths now apply the same routing and job options. This includes `dispatch()`,
+`dispatchMany()`, manual schedule triggers, and schedules claimed by workers.
+
+The routing order is now consistent across these paths:
+
+1. Fluent overrides such as `.toQueue()` and `.with()`
+2. Static `Job.options`
+3. The Adapter configured for the selected queue
+4. The queue manager's default Adapter
+
+Queue, Adapter, priority, custom job name, creation timestamp, and schedule provenance are therefore
+preserved consistently regardless of how a job is dispatched. Static job options are resolved when
+the fluent builder runs, so changes made between builder creation and execution are applied.
+
+The Sync adapter and Worker execution paths now also share the same job lifecycle behavior,
+including context construction, dependency injection through `jobFactory`, execution wrappers,
+timeouts, retries, failed hooks, and tracing.
+
+## Upgrade Notes
+
+A job routed to a queue with `queues.<name>.adapter` now uses that Adapter when neither `.with()` nor
+`Job.options.adapter` selects another one. Previously, some dispatch paths could incorrectly fall
+back to the queue manager's default Adapter. Verify that a Worker is running for every Adapter used
+by queue configuration.
+
+Explicit fluent options continue to take precedence over static job options.

.changelog/hot-reloading-jobs.md

@@ -0,0 +1,44 @@
+# Hot Reloading Jobs
+
+## New Feature
+
+Workers can now execute the latest saved version of a job without restarting during development.
+
+Enable `hotReload` when initializing the queue manager. Jobs discovered from `locations` will then
+be resolved from their module again before every execution.
+
+```typescript
+await QueueManager.init({
+  default: 'redis',
+  adapters: {
+    redis: redis({ host: 'localhost', port: 6379 }),
+  },
+  locations: ['./app/jobs/**/*.ts'],
+  hotReload: process.env.NODE_ENV === 'development',
+})
+```
+
+Hot reload integrates with [Hot Hook](https://github.com/Julien-R44/hot-hook). The queue provides
+the dynamic import boundary, while the application remains responsible for installing and
+initializing Hot Hook. AdonisJS applications can use `node ace serve --hmr`; standalone worker
+processes must initialize Hot Hook themselves.
+
+`Locator.registerFromGlob()` also accepts the option directly:
+
+```typescript
+await Locator.registerFromGlob(['./app/jobs/**/*.ts'], { hotReload: true })
+```
+
+## Upgrade Notes
+
+Hot reload is disabled by default and should only be enabled in development.
+
+Only jobs discovered from `locations` or registered with `Locator.registerFromGlob()` can be
+reloaded. Jobs registered manually with `Locator.register()` do not have a module path to reload.
+
+Changes to the set of registered jobs still require a restart. This includes adding, deleting,
+moving, or renaming a job, as well as changing its configured `name`. A job that is already running
+keeps its current implementation; the next execution receives the updated version.
+
+Avoid import-time side effects in hot-reloaded job modules, since their module code can execute
+again after an invalidation.