@milehimikey/em 1.1.1 → 1.3.0

package/.claude/skills/event-modeling/templates/state.md

@@ -7,14 +7,30 @@ Keep it current at the end of every working session.
 # Event Modeling Progress — {{Model Name}}
 
 - **Model file:** `{{model-name}}.em`
-- **Current phase:** {{discover | model | slice}}
-- **Current step:** {{1–7, see methodology}}
+- **Current phase:** {{extract | discover | model | slice}}
+- **Current step:** {{1–7, see methodology; or extraction round R1–R7}}
 - **Last updated:** {{YYYY-MM-DD}}
 
 ## Session inputs
 - **Scope line:** {{one-line description of what's in/out of bounds for this model}}
 - **PRD / spec reference:** {{path, link, or "none"}}
 - **Headless/API model:** {{yes | no}}
+- **Source mode:** {{greenfield | extract-event-driven | extract-procedural}}
+- **Existing system refs:** {{repo paths, event-schema/topic locations, docs — or "n/a"}}
+
+## Participants
+<!-- Populate at session start. Live workshop: one human proxy relays questions to the room;
+     attribute every answer/decision in the Decisions log to a named participant here. -->
+- {{Name}} — {{role}} — {{domain area}}
+
+## Extraction progress (existing-system models only — delete for greenfield)
+- [ ] R1. Candidate events (extracted/synthesized, filtered, confirmed)
+- [ ] R2. Timeline order (as-is narrative, actors/callers, first render)
+- [ ] R3. Commands / inputs
+- [ ] R4. Read models / outputs (validate from here)
+- [ ] R5. Boundaries & reactions (two-slice splits)
+- [ ] R6. Gap & TBD reconciliation
+- [ ] R7. Convergence (render + validate clean, user confirmed as-is)
 
 ## Steps completed
 - [ ] 1. Brainstorm events
@@ -26,14 +42,18 @@ Keep it current at the end of every working session.
 - [ ] 7. Evaluate completeness (`em validate` clean)
 
 ## Decisions log
-<!-- Resolved choices, with the reasoning, so they aren't re-litigated. -->
-- {{YYYY-MM-DD}}: {{decision}} — {{why}}
+<!-- Resolved choices, with the reasoning, so they aren't re-litigated. In a live workshop,
+     attribute each entry to the participant who made the call (see Participants above). -->
+- {{YYYY-MM-DD}}: {{decision}} — {{why}} — by {{participant, if a live workshop}}
 
 ## Open questions / parking lot
-<!-- Unresolved items to bring back to the user. Never guess these. -->
-- [ ] {{question}}
+<!-- Unresolved items to bring back to the user. Never guess these. Metadata is optional and
+     flat — add only what's known: source (ticket/conversation that spawned it), blocked on
+     (who/what), revisit (when). -->
+- [ ] {{question}} — source: {{ticket/conversation link, optional}} — blocked on: {{who/what, optional}} — revisit: {{when, optional}}
 
 ## Slice inventory
-| Slice | Pattern | Doc status |
-|-------|---------|------------|
-| {{Slice Name}} | {{State Change/View/Automation/Translation}} | {{none / draft / ready}} |
+<!-- Deliberately NOT a table: the canonical slice index (slice, pattern, status, doc link)
+     lives in README.md's "Slices" section — one source of truth, updated there. This file
+     only tracks resumable session state. -->
+See `README.md` → **Slices** for the slice index and per-slice doc status.

package/README.md

@@ -1,187 +1,86 @@
-# em — AI friendly event modeling
+# em — event modeling in plain text
 
 `em` is a command-line tool for [Event Modeling](https://eventmodeling.org/). You write a
-model in a small, **plain-text, slice-first DSL** (`.em`) and `em` renders it to a clean,
-deterministic diagram (SVG by default, PNG on request). Because the source is just text —
-diff-able, reviewable, and unambiguous — it's as easy for an LLM to generate and edit as it
-is for a person to write by hand. Layout is a **strict grid**: swimlane rows and
-time-ordered slice columns stay perfectly aligned with no manual offsets.
+model in a small, slice-first DSL and `em` renders it as a clean, deterministic diagram.
+Because the source is plain text — diff-able, reviewable, unambiguous — it's as easy for an
+AI to write and edit as it is for a person, and `em validate` keeps either one honest.
 
-```
-examples/order-fulfillment.em  ->  em render  ->  order-fulfillment.svg
-```
+![An order-fulfillment event model rendered by em](https://raw.githubusercontent.com/milehimikey/em/main/examples/order-fulfillment.svg)
 
-Rendering is **self-contained** — Graphviz runs as bundled WebAssembly and PNG is
-rasterized in-process, so there's nothing to `apt`/`brew` install for SVG or PNG output.
+The source for that diagram is [about 70 lines of text](examples/order-fulfillment.em).
 
 ## Install
 
 ```bash
-npm install -g @milehimikey/em     # then `em` is on your PATH
+npm install -g @milehimikey/em
 ```
 
-Requires **Node ≥ 18**. SVG and PNG need no other tools. PDF (and other Graphviz raster
-formats) are optional and use a system `rsvg-convert` (librsvg) if one is installed.
-
-Run without installing:
-
-```bash
-npx @milehimikey/em init model.em
-npx @milehimikey/em render model.em
-```
+Requires Node ≥ 18. SVG and PNG rendering are fully self-contained (Graphviz runs as
+bundled WebAssembly); nothing else to install. PDF is optional — see
+[docs/dependencies.md](docs/dependencies.md).
 
 ## Quickstart
 
 ```bash
 em init model.em          # scaffold a starter model
 em render model.em        # -> model.svg  (open it in a browser)
-em watch model.em         # re-render on every save
+em watch model.em --serve # live browser view, re-renders on every save
 em validate model.em      # check event-modeling rules
 ```
 
-A `.em` model is a list of **slices** (vertical time steps), each holding elements that fall
-into swimlane rows:
+A model is a list of slices — vertical time steps, read left to right — whose elements land
+in swimlane rows:
 
-```
+```em
 model "Order Fulfillment"
 
-persona Customer           # UI swimlanes (top), one row per persona
-context Order              # event swimlanes (bottom), one row per context
-context Payment
-
-slice "Browse Catalog" {           # each slice is one column (time, left -> right)
-  ui Product Catalog @Customer     # @Persona places the screen in a persona row
-  command Place Order {            # a `{ … }` block declares the element's fields
-    customerId
-    total: Money                   # optional `: Type` annotation
-  }
-  event Order Placed @Order note "notes/order-placed.md" {   # note "…" links docs
-    orderId
-    total: Money
-  }
+persona Customer
+context Order
+
+slice "Browse Catalog" {
+  ui Product Catalog @Customer
+  command Place Order
+  event Order Placed @Order
 }
 
 slice "View Open Orders" {
-  view Open Orders from "Order Placed"   # from "<event>" wires the data flow
+  view Open Orders from "Order Placed"
   ui Order List @Customer
 }
 ```
 
-## The four patterns
-
-Event Modeling is built from four patterns, all expressible as slices:
-
-| Pattern | Flow | DSL elements |
-|---|---|---|
-| **Input** (state change) | UI → command → event | `ui`, `command`, `event` |
-| **Output** (state view) | event → read model → UI | `event`, `view from "…"`, `ui` |
-| **Automation** | read model (todo) → processor → command → event | `view from "…"` + `processor`, then `command` + `event` |
-| **Translation** | external read model → translation → command → event | `view from "…"` + `translation`, then `command` + `event` |
+The [tutorial](docs/tutorial.md) builds a complete model from an empty file in about twenty
+minutes.
 
-Automation/translation slices are **not** triggered by a command — they react to a read
-model (a "todo list") or a timer and *issue* a command when done. The automation slice
-contains **only** the read model it reads and the processor/translation; the command it
-triggers (and that command's event) is the **next** slice.
+## Model with AI
 
-## DSL reference
-
-### Element keywords → swimlane bands (top → bottom)
-
-0. *(header)* — each slice name is rendered as a title cell in the top row
-1. `automation` / `processor` / `saga` / `translation` — **Automation** band (only shown if used)
-2. `ui` — **persona** rows (one per `persona`)
-3. `command` + `view` — the **API** row (commands and read models share one lane)
-4. `event` — **context/concept** rows (one per `context`)
-
-Commands and read models share the **API** row, so a slice holds *either* a command *or* a
-read model. The empty API lane is dropped when a model has neither; pass `--keep-empty-lanes`
-to keep it.
-
-`@Persona` / `@Context` choose the row within a band (undeclared tags create a new row).
-`view <Name> again [from "Event", …]` declares a LATER INSTANCE of an already-declared read
-model — the Event Modeling device for keeping the timeline forward-only as a view evolves.
-Instances are one logical view: the first declaration owns the `note` doc; each instance lists
-the events that reach it there; instances are linked left-to-right with a continuity arrow, and
-reactions (`processor … from "View"`) read the nearest instance at-or-before their slice.
-
-`view … from "Event"[, "Event2"]` declares which events feed a read model and draws the
-data-flow arrow. Arrows within a slice are inferred from the pattern; use `arrow A -> B` for
-anything extra (e.g. a read model feeding a different screen).
-
-### Fields
-
-Any element can declare **data fields** in a `{ … }` block — the data it accepts (command),
-records (event), projects (read model), or shows (UI). Each field is `name` with an optional
-`: Type`; write one per line, or inline and comma-separated:
-
-```
-command Place Order {            # one per line
-  customerId
-  items: List<LineItem>
-  total: Money
-}
-
-event Payment Requested @Payment { orderId, amount: Money }   # inline
-```
-
-Fields render **in the box**, UML-style: the name, a divider rule, then the fields. The box
-grows to fit them (width stays fixed, so columns stay aligned), and arrows still anchor to
-the box edges so the lines stay stable. A field block coexists with `note`/`from` clauses on
-the same element. Fields are the foundation of the later event-modeling phases (the slicing /
-information-completeness process); field-level validation across slices is planned.
-
-### Notes
-
-Any element can carry `note "path.md"` (valid on every keyword). The prose lives in the
-markdown file — keeping the diagram uncluttered — and the box gets a small **numbered
-folded-corner marker** in its top-right corner. A **legend** is appended below the diagram
-mapping each number to its element and note file, so even a static export tells you which
-note belongs to which box.
-
-In **SVG** output the markers and legend rows are links; clicking one opens the markdown
-file. Links resolve relative to the **output SVG's location**, so they keep working whether
-the SVG is rendered beside the model or into another folder (as long as the notes travel
-with it). Open the SVG in a **web browser** to use the links — image viewers like macOS
-Preview/Quick Look show the markers but ignore SVG hyperlinks. Raster output (PNG/PDF) can't
-carry links — that's what the footnote numbers + legend are for.
-
-## Commands
+`em` ships a Claude Code skill that runs a facilitated Event Modeling session: the AI asks
+the questions, you supply the domain, and the model renders live as it grows.
 
 ```bash
-em init [file]                        # scaffold a starter model (default: model.em)
-em render <file> [-o out.svg]         # render (format from -o extension or -T)
-em render <file> -o out.png           # PNG (in-process, no system deps)
-em render <file> --emit-dot           # print the generated DOT instead of rendering
-em render <file> --keep-empty-lanes   # don't collapse the API lane when empty
-em watch <file> [-o out.svg]          # re-render on every save
-em validate <file>                    # check event-modeling rules (non-zero exit on errors)
+em skill install          # copy the skill into .claude/skills/event-modeling/
 ```
 
-## Validation rules (`em validate`)
-
-- two same-band elements in one slice (collision) → **error** (split into separate slices)
-- a read model whose `from "Event"` doesn't exist → **error**
-- **time flows left to right** (the Two Laws): an event feeding an EARLIER view instance,
-  a reaction reading a view that only exists later, or an explicit backward `arrow` → **error**
-  (fix: add `view X again` at the point on the timeline where the event lands)
-- `again` on a view with no earlier declaration → **error**; `again` on non-views → parse error
-- multi-event slices always render as a FAN from the command (never event→event); fanned
-  arrows route around the column gutter so they cannot read as a chain
-- an automation/translation whose `from "<read model>"` doesn't exist → **error**
-- an `arrow` endpoint that matches no element → **error**
-- an automation/translation slice that also holds the command it triggers → **warning**
-- a command that records no event → **warning**
-- a read model with no source event → **warning**
-- a name defined more than once and referenced → **warning** (resolves to first)
+Then run `/event-modeling` in Claude Code. See [docs/ai-workflow.md](docs/ai-workflow.md)
+for the phases and what a session produces, and the
+[em-with-ai repository](https://github.com/milehimikey/em-with-ai) for a ~50-slice model
+built this way.
 
 ## Documentation
 
-- [docs/timeline-model.md](docs/timeline-model.md) — the Two Laws of the Timeline (forward-only
-  validation, `view … again`)
-- [docs/why-dot-not-plantuml.md](docs/why-dot-not-plantuml.md) — why DOT + the strict-grid /
-  self-drawn-edges architecture
-- [docs/features.md](docs/features.md) — full feature list and roadmap
-- [docs/dependencies.md](docs/dependencies.md) — how rendering works with no system deps
+| Doc | What it answers |
+|---|---|
+| [docs/tutorial.md](docs/tutorial.md) | Learn the tool by building a model from scratch |
+| [docs/patterns.md](docs/patterns.md) | The four Event Modeling patterns and their DSL shapes |
+| [docs/dsl.md](docs/dsl.md) | Full DSL reference: keywords, `from`, `again`, fields, notes |
+| [docs/cli.md](docs/cli.md) | Every command and flag |
+| [docs/validation.md](docs/validation.md) | Every rule `em validate` checks, and the fixes |
+| [docs/ci.md](docs/ci.md) | Copy-paste GitHub Actions recipe: validate `.em` changes in CI |
+| [docs/timeline.md](docs/timeline.md) | The Two Laws of the Timeline |
+| [docs/ai-workflow.md](docs/ai-workflow.md) | The Claude Code skill: install, phases, artifacts |
+| [docs/dependencies.md](docs/dependencies.md) | What's bundled vs. what needs a system install |
+| [docs/architecture.md](docs/architecture.md) | How rendering works; why Graphviz, not PlantUML |
+| [docs/roadmap.md](docs/roadmap.md) | What's planned |
 
 ## Development
 
@@ -192,32 +91,6 @@ npm test               # vitest
 npx tsx src/cli.ts <command> ...   # run straight from source
 ```
 
-## AI Assistant (Claude Code)
-
-`em` ships a **Claude Code skill** that guides you and your team through Event Modeling using the 7-step process and 4 design patterns, producing implementation-ready slice specifications. The AI drives the model — asking focused questions, never guessing domain facts — while `em validate` keeps the diagram honest.
-
-**Install the skill into your project:**
-
-```bash
-em skill install          # copies the skill into .claude/skills/event-modeling/
-em skill install --force  # overwrite an existing installation
-```
-
-Then, in Claude Code, run:
-
-```
-/event-modeling           # start (or resume) a guided session
-/event-modeling discover  # steps 1–4: brainstorm events, timeline, commands, read models
-/event-modeling model     # steps 5–7: swimlanes, patterns, completeness check
-/event-modeling slice     # deep implementation specs, one per slice
-/event-modeling watch     # open a live browser view for team modeling sessions
-/event-modeling validate  # run em validate and resolve all diagnostics
-```
-
-Sessions are **resumable** — the skill checkpoints progress in `.event-modeling.md` so you can continue across conversations.
-
-For a complete worked example (a headless CPQ system with ~50 slices), see the [em-with-ai repository](https://github.com/milehimikey/em-with-ai).
-
 ## License
 
 [MIT](LICENSE) © milehimikey

package/dist/cli/diff-inputs.d.ts

@@ -0,0 +1,44 @@
+/** Resolved `em diff` invocation, or a user-facing `error` for an invalid form. */
+export type DiffPlan = {
+    error: string;
+} | {
+    form: "files";
+    oldFile: string;
+    newFile: string;
+} | {
+    form: "git";
+    file: string;
+    from: string;
+    to?: string;
+};
+/**
+ * Validate the `em diff` argument/flag combination. Pure — no I/O. The two forms
+ * (two files, or one file across git revisions) are mutually exclusive.
+ */
+export declare function planDiffArgs(oldFile: string, newFile: string | undefined, opts: {
+    from?: string;
+    to?: string;
+}): DiffPlan;
+/** The slice of a `spawnSync` result `resolveRevision` reads; lets tests inject a fake git. */
+export interface GitResult {
+    status: number | null;
+    stdout: string;
+    stderr: string;
+}
+export type GitRunner = (args: string[]) => GitResult;
+/** Default runner: really invokes `git` (array args — no shell, no injection). */
+export declare const realGit: GitRunner;
+/** File content at a git revision, or a user-facing `message` for each failure mode. */
+export type RevisionResult = {
+    ok: true;
+    content: string;
+} | {
+    ok: false;
+    message: string;
+};
+/**
+ * Resolve `file`'s content at git revision `rev` via `git show <rev>:<repo-relative-path>`.
+ * The git runner is injectable so the not-a-repo / not-tracked / bad-rev branches are
+ * unit-testable without a real repository.
+ */
+export declare function resolveRevision(file: string, rev: string, runGit?: GitRunner): RevisionResult;

package/dist/cli/diff-inputs.js

@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: MIT
+// Testable input handling for `em diff`: argument-form validation and
+// git-revision resolution, factored out of cli.ts so the branching logic can be
+// unit-tested without spawning a subprocess or a real git repo (cli.ts keeps the
+// process.exit/console wiring; see test/diff-inputs.test.ts).
+import { spawnSync } from "node:child_process";
+import { dirname, resolve } from "node:path";
+/**
+ * Validate the `em diff` argument/flag combination. Pure — no I/O. The two forms
+ * (two files, or one file across git revisions) are mutually exclusive.
+ */
+export function planDiffArgs(oldFile, newFile, opts) {
+    if (opts.from) {
+        if (newFile) {
+            return {
+                error: "em diff: cannot combine two file arguments with --from/--to — use one form or the other",
+            };
+        }
+        return { form: "git", file: oldFile, from: opts.from, to: opts.to };
+    }
+    if (opts.to) {
+        return { error: "em diff: --to requires --from" };
+    }
+    if (!newFile) {
+        return {
+            error: "em diff: provide two files (`em diff old.em new.em`) or one file with --from <rev>",
+        };
+    }
+    return { form: "files", oldFile, newFile };
+}
+/** Default runner: really invokes `git` (array args — no shell, no injection). */
+export const realGit = (args) => {
+    const r = spawnSync("git", args, { encoding: "utf8" });
+    return { status: r.status, stdout: r.stdout ?? "", stderr: r.stderr ?? "" };
+};
+/**
+ * Resolve `file`'s content at git revision `rev` via `git show <rev>:<repo-relative-path>`.
+ * The git runner is injectable so the not-a-repo / not-tracked / bad-rev branches are
+ * unit-testable without a real repository.
+ */
+export function resolveRevision(file, rev, runGit = realGit) {
+    const abs = resolve(file);
+    const toplevel = runGit(["-C", dirname(abs), "rev-parse", "--show-toplevel"]);
+    if (toplevel.status !== 0) {
+        return { ok: false, message: `em diff: ${file} is not inside a git repository (needed for --from/--to)` };
+    }
+    const repoRoot = toplevel.stdout.trim();
+    const lsFiles = runGit(["-C", repoRoot, "ls-files", "--full-name", "--", abs]);
+    const relPath = lsFiles.stdout.trim().split("\n")[0];
+    if (!relPath) {
+        return { ok: false, message: `em diff: ${file} is not tracked by git in ${repoRoot}` };
+    }
+    const show = runGit(["-C", repoRoot, "show", `${rev}:${relPath}`]);
+    if (show.status !== 0) {
+        return {
+            ok: false,
+            message: `em diff: cannot read ${relPath} at revision "${rev}": ${(show.stderr || "").trim() || "unknown git error"}`,
+        };
+    }
+    return { ok: true, content: show.stdout };
+}
+//# sourceMappingURL=diff-inputs.js.map

package/dist/cli/diff-inputs.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"diff-inputs.js","sourceRoot":"","sources":["../../src/cli/diff-inputs.ts"],"names":[],"mappings":"AAAA,+BAA+B;AAC/B,sEAAsE;AACtE,gFAAgF;AAChF,iFAAiF;AACjF,8DAA8D;AAE9D,OAAO,EAAE,SAAS,EAAE,MAAM,oBAAoB,CAAC;AAC/C,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAQ7C;;;GAGG;AACH,MAAM,UAAU,YAAY,CAC1B,OAAe,EACf,OAA2B,EAC3B,IAAoC;IAEpC,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;QACd,IAAI,OAAO,EAAE,CAAC;YACZ,OAAO;gBACL,KAAK,EAAE,yFAAyF;aACjG,CAAC;QACJ,CAAC;QACD,OAAO,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,OAAO,EAAE,IAAI,EAAE,IAAI,CAAC,IAAI,EAAE,EAAE,EAAE,IAAI,CAAC,EAAE,EAAE,CAAC;IACtE,CAAC;IACD,IAAI,IAAI,CAAC,EAAE,EAAE,CAAC;QACZ,OAAO,EAAE,KAAK,EAAE,+BAA+B,EAAE,CAAC;IACpD,CAAC;IACD,IAAI,CAAC,OAAO,EAAE,CAAC;QACb,OAAO;YACL,KAAK,EAAE,oFAAoF;SAC5F,CAAC;IACJ,CAAC;IACD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,CAAC;AAC7C,CAAC;AAUD,kFAAkF;AAClF,MAAM,CAAC,MAAM,OAAO,GAAc,CAAC,IAAI,EAAE,EAAE;IACzC,MAAM,CAAC,GAAG,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,EAAE,QAAQ,EAAE,MAAM,EAAE,CAAC,CAAC;IACvD,OAAO,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,IAAI,EAAE,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,IAAI,EAAE,EAAE,CAAC;AAC9E,CAAC,CAAC;AAKF;;;;GAIG;AACH,MAAM,UAAU,eAAe,CAAC,IAAY,EAAE,GAAW,EAAE,SAAoB,OAAO;IACpF,MAAM,GAAG,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC1B,MAAM,QAAQ,GAAG,MAAM,CAAC,CAAC,IAAI,EAAE,OAAO,CAAC,GAAG,CAAC,EAAE,WAAW,EAAE,iBAAiB,CAAC,CAAC,CAAC;IAC9E,IAAI,QAAQ,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC1B,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,OAAO,EAAE,YAAY,IAAI,0DAA0D,EAAE,CAAC;IAC5G,CAAC;IACD,MAAM,QAAQ,GAAG,QAAQ,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC;IACxC,MAAM,OAAO,GAAG,MAAM,CAAC,CAAC,IAAI,EAAE,QAAQ,EAAE,UAAU,EAAE,aAAa,EAAE,IAAI,EAAE,GAAG,CAAC,CAAC,CAAC;IAC/E,MAAM,OAAO,GAAG,OAAO,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC;IACrD,IAAI,CAAC,OAAO,EAAE,CAAC;QACb,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,OAAO,EAAE,YAAY,IAAI,6BAA6B,QAAQ,EAAE,EAAE,CAAC;IACzF,CAAC;IACD,MAAM,IAAI,GAAG,MAAM,CAAC,CAAC,IAAI,EAAE,QAAQ,EAAE,MAAM,EAAE,GAAG,GAAG,IAAI,OAAO,EAAE,CAAC,CAAC,CAAC;IACnE,IAAI,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACtB,OAAO;YACL,EAAE,EAAE,KAAK;YACT,OAAO,EAAE,wBAAwB,OAAO,iBAAiB,GAAG,MAAM,CAAC,IAAI,CAAC,MAAM,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,IAAI,mBAAmB,EAAE;SACtH,CAAC;IACJ,CAAC;IACD,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,OAAO,EAAE,IAAI,CAAC,MAAM,EAAE,CAAC;AAC5C,CAAC"}