> ## Documentation Index > Fetch the complete documentation index at: https://docs.monolex.ai/llms.txt > Use this file to discover all available pages before exploring further. # Boot Sequence Tracer > Trace indexed web-app initialization order — ESM evaluation, DOM handlers, configured priorities, and guarded init paths. `monogram boot` reconstructs the initialization sequence that Monogram can observe from an indexed JavaScript/TypeScript application. It connects import order, global registration, DOM event handlers, configured priority arrays, and guarded initialization paths, then routes each finding back into the ordinary graph commands. *Documents the public OpenCLIs release `monogram 0.98.11`.* ## Quick start ```bash theme={null} # Build or refresh the project index monogram index . # Read-only trace using the detected/configured entry monogram boot # Optional: detect project-specific patterns and write the config monogram boot init # Rerun with .monogram/boot.toml monogram boot ``` Override the entry file without changing configuration: ```bash theme={null} monogram boot src/main.ts ``` ## What the trace answers * Which ESM modules evaluate before the entry point completes? * Which `window.*` globals and event handlers are registered, and from where? * In what import-registration order do `DOMContentLoaded` handlers appear? * Which configured initializer objects run by priority? * Which configured init functions are guarded by bootstrap flags? The result is index-observed evidence. Dynamic imports, runtime-generated handlers, dependency injection, and browser behavior outside the indexed source may require a live [MonoSurf](/monosurf) observation as a second proof layer. ## Phase 1: ESM evaluation Monogram walks the indexed import graph from the entry and reports module evaluation order with relevant registration events. ```text theme={null} [Phase 1: ESM Module Evaluation] IMPORT src/modules/core/utils-core.ts IMPORT src/modules/terminal/terminal-scrollbar.ts :517 SET window.terminalWheelScrolling in onWheel IMPORT src/main.ts :87 SET window.__MONOLEX_MAIN_BOOTSTRAP__ in ``` Typical rows: | Row | Meaning | | -------- | --------------------------------------------- | | `IMPORT` | Module reached through the entry import graph | | `SET` | Indexed `window.X = ...` registration | | `REG` | Indexed event-listener registration | ## Phase 2: DOM handlers `DOMContentLoaded` handlers are shown in the registration order implied by module evaluation, with calls made by each handler. ```text theme={null} [Phase 2: DOMContentLoaded Handlers] #1 (src/modules/theme/theme-manager.ts:2279) init #2 (src/main.ts:1726) preloadFonts initializeWindowModules ``` This proves the indexed registration path. It does not claim that asynchronous work inside the handlers finishes in the same order. ## Phase 3: configured priorities When `.monogram/boot.toml` describes a priority array, Monogram reads its objects and displays the initialization order. ```text theme={null} [Phase 3: Priority-Based Module Init] Priority 52: P52 new NativeMdViewer() -> nativeMdViewer Priority 100: P100 terminalSessionPersistence.init() ``` This phase needs configuration because object-field conventions differ across projects. ## Phase 4: configured guards Guard rules identify candidate init functions whose execution is controlled by bootstrap flags. ```text theme={null} [Guarded init paths] src/modules/file/file-explorer-init.ts:657 maybeAutoInitFileExplorer -> window.__*__ ``` A guard match is a static candidate, not proof that the runtime branch is always unreachable. Confirm the flag's writers and callers with `grep`, `provenance`, `context`, and `chain`. ## Configuration ### Generate it ```bash theme={null} monogram boot init ``` The command detects likely entry files, arrays containing repeated `priority` fields, and init-style functions with window-flag guards. It writes: ```text theme={null} .monogram/boot.toml ``` Example: ```toml theme={null} entry = "./src/main.ts" [[priority_array]] file = "*module-init*" fields = ["name", "priority", "type", "functionName", "instanceName"] [[dead_guard]] function = "maybeAutoInit*" flag = "window.__*__" ``` ### Refine it manually ```toml theme={null} [[priority_array]] file = "*app-config*" fields = ["name", "priority"] [[dead_guard]] function = "lazyInit*" flag = "__APP_READY__" ``` Keep patterns project-relative and narrow enough that a match has one understandable owner. ## Drill from boot into structural proof Boot is the overview; use the regular commands for the owning path. ```bash theme={null} # Boot names an initializer monogram context initializeWindowModules --code 80 monogram chain initializeWindowModules --callees --depth 2 # Boot names the module containing a priority array monogram deps src/module-init.ts monogram rdeps src/module-init.ts # Boot names a global or event registration monogram grep "__MONOLEX_MAIN_BOOTSTRAP__" --file src -C 3 monogram grep "DOMContentLoaded" --file src -C 3 # Trace the guard value's source monogram provenance __MONOLEX_MAIN_BOOTSTRAP__ ``` Keep filtering and bounded context inside Monogram so the `[NEXT]` trail retains the file, graph, and rank evidence. ## CLI and MCP boundary | Surface | Behavior | | ----------------------- | --------------------------------------------------------------------------------- | | `monogram boot` | Read-only trace; uses `.monogram/boot.toml` when present | | `monogram boot ` | Read-only trace with an entry override | | `monogram boot init` | Writes `.monogram/boot.toml` | | MCP `monogram_boot` | Read-only; the `init` write submode is not exposed through the 50-tool MCP schema | `MONOGRAM_PREPARED_INDEX=1` blocks non-JSON `boot init` with the protected-index guard. Read-only tracing remains available against the prepared snapshot. ## Verification flow ```bash theme={null} monogram stats monogram boot monogram context --code 80 monogram chain --callees --depth 2 ``` If the runtime order itself matters, add a browser/runtime trace after the source proof. Keep the two conclusions separate: Monogram shows the indexed initialization structure; the live browser proves what actually executed in that run.