Boot Sequence Tracer

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.6.

Quick start

# 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:

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 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.

[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 <top>

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.

[Phase 2: DOMContentLoaded Handlers]
  #1 <on:DOMContentLoaded:2279> (src/modules/theme/theme-manager.ts:2279)
       init

  #2 <on:DOMContentLoaded:1726> (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.

[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.

[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

monogram boot init

The command detects likely entry files, arrays containing repeated priority fields, and init-style functions with window-flag guards. It writes:

.monogram/boot.toml

Example:

entry = "./src/main.ts"

[[priority_array]]
file = "*module-init*"
fields = ["name", "priority", "type", "functionName", "instanceName"]

[[dead_guard]]
function = "maybeAutoInit*"
flag = "window.__*__"

Refine it manually

[[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.

# 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 <entry>`	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

monogram stats
monogram boot
monogram context <top-init-symbol> --code 80
monogram chain <top-init-symbol> --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.

Get Started

Articles

So Anthropic

User Guide

Philosophy

Applied Philosophy

Architecture

Gestalt Color

Transparency

Terminal Core

Features

VariableMD

Research

CodexMono

OpenCLIs

vpncli

MonoSurf

AI-CLIs

Quick start

What the trace answers

Phase 1: ESM evaluation

Phase 2: DOM handlers

Phase 3: configured priorities

Phase 4: configured guards

Configuration

Generate it

Refine it manually

Drill from boot into structural proof

CLI and MCP boundary

Verification flow

​Quick start

​What the trace answers

​Phase 1: ESM evaluation

​Phase 2: DOM handlers

​Phase 3: configured priorities

​Phase 4: configured guards

​Configuration

​Generate it

​Refine it manually

​Drill from boot into structural proof

​CLI and MCP boundary

​Verification flow

Quick start

What the trace answers

Phase 1: ESM evaluation

Phase 2: DOM handlers

Phase 3: configured priorities

Phase 4: configured guards

Configuration

Generate it

Refine it manually

Drill from boot into structural proof

CLI and MCP boundary

Verification flow