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

Read-only runtime status of a single runtime record (Component, Layout, ErrorPage,
Page, Stylesheet, JsHook): its latest Oban compile job and whether its compiled
artifact is present — a module loaded in RAM (module-backed resources) or the
site's combined CSS/JS bundle (asset-backed Stylesheet/JsHook).

`compute/2` returns a plain map consumed by
`MishkaCmsCoreWeb.Live.Admin.Components.RuntimeStatusTimeline`. It never compiles
or writes — only `:erlang.module_loaded/1`, `AssetsState.exists?/2`, and one
`oban_jobs` read.

Lazy parts (`precompile: false` — a Page, a Layout, an Error Page or a Component)
are NOT compiled until the first request that needs them, so "module not loaded"
is the normal `:lazy_ready` state, not a failure. See
`MishkaCmsCore.Runtime.Workers.RuntimeCompilerWorker` `compile?/3`.

# `compute`

Compute the status map for `record` of `resource`.

# `config`

Per-resource shape: artifact kind, module-name key/type, label.

`key_field` names the module (`Helpers.module_name/3` hashes it); `lookup_field` names the column
the compiler searches the row by. They differ for everything but a Component: a Layout's module is
keyed by `id` while the compile worker finds the row by `path`, which is why one field cannot
serve both.

---

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