# `MishkaCmsCore.Runtime.Handlers.RuntimeOrchestrator`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/handlers/runtime_orchestrator.ex#L5)

Central rebuild coordinator for the runtime pipeline.

Single-resource edits flow through `SendToOban` → `RuntimeCompilerWorker`,
which already debounces/dedups per-site asset jobs. This module owns the
OTHER path: a **bulk** write (e.g. the UI-kit installer inserts hundreds of
rows in one transaction with `defer_runtime: true`) that must rebuild the
runtime **once** for the final result instead of per row.

`sync_after_bulk/1` rebuilds from the DB using the same steps boot uses:

  1. component templates + modules (`BootHandler.compile_components/0`), and for each
     component row the batch wrote, a module a render had already built is built again from it
     (`RuntimeCompilerWorker.refresh_after_bulk/1`)
  2. JS-hook templates (`BootHandler.create_js_hooks_template/0`)
  3. stylesheet load (`BootHandler.load_stylesheets/0`)
  4. for a global change: drop + rebuild the shared base once
  5. fan out per-site asset jobs (unique + debounced)

Step 4 precedes 5 so every site recompiles against a fresh shared base
(avoids the stale/partial-base bug). Asset jobs are deduped in
`BootHandler.asset_job/4`, so the fan-out can never storm.

No-op under `config :mishka_cms_core, env_test?: true` so tests stay fast and
don't depend on a populated `AssetsState`.

See `MishkaCmsCore.Runtime.Handlers.BootHandler` and
`MishkaCmsCore.Runtime.Compilers.TailwindCompiler`.

# `sync_after_bulk`

```elixir
@spec sync_after_bulk(keyword()) :: :ok
```

Rebuild the runtime once after a deferred bulk write.

## Options

  * `:scope` — `:global` (default) rebuilds the shared base and fans out to
    every active site; `{:site, site_id}` scopes the rebuild to one site.
  * `:kinds` — which resource kinds were touched (default
    `[:component, :js_hook, :stylesheet]`); limits which build steps run.
  * `:components` — the component rows the batch wrote (default `[]`). Each one's module is
    brought up to date as a single save of it would bring it — see
    `RuntimeCompilerWorker.refresh_after_bulk/1`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*