From 7083f176f2607cf756db4f40ec5ea26d8b7b2993 Mon Sep 17 00:00:00 2001 From: Kyle Sexton <153232337+kyle-sexton@users.noreply.github.com> Date: Thu, 30 Jul 2026 02:08:25 -0400 Subject: [PATCH 1/2] docs(event-storming): clear the Design-Level y-overlap and collapse the duplicate scheme MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Design-Level Y-Coordinate Table packed Actors (-200), Commands (-100) and Aggregates (0) into 100px gaps, under the ~199px threshold these layouts use. An x-aware check confirms both overlaps: rows in one phase table share an x band, so x always intersects and the test reduces to adjacent |dy|. Rows above the Aggregates baseline now sit 250px apart rather than the minimum that clears the threshold — 250px is what this file's own Spacing summary already states for vertical rows, and 200px would clear a "~199px" threshold by a single pixel. Aggregates stays the y=0 baseline and nothing below it moves. The orphaned block after the table restated a third coordinate scheme (Actors -250, Read Models -450, Hot Spots -250, alternatives +250) matching neither canonical table, and described Commands sitting on the y=0 baseline — true of the single-flow model it was written for, not of Design-Level, where Aggregates holds y=0. Its y literals are gone. What it uniquely carried survives: the flow reads left to right at 400px per item, and a step is a column, so the example now names table rows instead of restating their values. Refs melodic-software/medley#1555 Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01RhS3T7ShwJgKTrvk2Mvd3C --- .../simulation/reference/miro-integration.md | 45 +++++++------------ 1 file changed, 17 insertions(+), 28 deletions(-) diff --git a/plugins/event-storming/skills/simulation/reference/miro-integration.md b/plugins/event-storming/skills/simulation/reference/miro-integration.md index 3c4c912f9b..024966676e 100644 --- a/plugins/event-storming/skills/simulation/reference/miro-integration.md +++ b/plugins/event-storming/skills/simulation/reference/miro-integration.md @@ -174,10 +174,10 @@ Persona 1 sits at the `y=0` timeline baseline. | Row | y | Purpose | |-----|---|---------| -| BC Contracts (inbound) | -600 | Consumed events from other BCs | -| Read Models | -400 | Information panels | -| Actors | -200 | Who issues commands | -| Commands | -100 | Blue imperative actions | +| BC Contracts (inbound) | -1000 | Consumed events from other BCs | +| Read Models | -750 | Information panels | +| Actors | -500 | Who issues commands | +| Commands | -250 | Blue imperative actions | | **Aggregates** | **0** | Light yellow — blank first, named last | | Business Rules | 300 | Gray — invariants (stack at y=300, 550, 800) | | Domain Events | 1100 | Orange — outcomes | @@ -185,33 +185,22 @@ Persona 1 sits at the `y=0` timeline baseline. | What-if challenges | 1700 | Red hot spots | | BC Contracts (outbound) | 2000 | Published events | -**Main flow (y=0 baseline):** - -- Commands, Events, Policies all sit on y=0 -- Flow reads left-to-right, incrementing x by 400 per item - -**Above the flow (negative y = up):** - -- Actors: y=-250 (directly above their command) -- Read Models: y=-450 (above the actor) -- Hot Spots: y=-250 (above the related event) - -**Below the flow (positive y = down):** - -- Alternative outcomes: y=+250 (below the happy path event) +**Reading the layout:** every row's y comes from that phase's Y-Coordinate Table +above — negative is up, positive is down, and the bolded row is the baseline. The +tables are the only place y values are written down; nothing below restates them. -**Example: one complete flow segment** +**Horizontal placement:** the flow reads left to right, incrementing x by 400 per +item, independent of phase. A command and the actor that issues it share one x and +differ only by row, so a single flow segment is a column per step: ``` -Read Model: x=0, y=-450 -Actor: x=0, y=-250 -Command: x=0, y=0 -Domain Event: x=400, y=0 (happy path) -Event (alt): x=400, y=250 (rejection/failure) -Hot Spot: x=400, y=-250 (above the event) -Policy: x=800, y=0 (reactive — "whenever") -Next Command: x=1200, y=0 (triggered by policy) -Next Event: x=1600, y=0 +Actor x=0 row: Actors +Command x=0 row: Commands +Domain Event x=400 row: Domain Events (happy path) +Event (alt) x=400 row: Alternative outcomes (rejection/failure) +Policy x=800 row: Domain Events (reactive — "whenever") +Next Command x=1200 row: Commands (triggered by policy) +Next Event x=1600 row: Domain Events ``` **Legend frame positioning and sizing:** From 32d006dc5184b3e4c1ef291e3950fe0e737e83d7 Mon Sep 17 00:00:00 2001 From: Kyle Sexton <153232337+kyle-sexton@users.noreply.github.com> Date: Thu, 30 Jul 2026 09:25:11 -0400 Subject: [PATCH 2/2] docs(event-storming): give Design-Level policies their own row MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Design-Level Y-Coordinate Table never carried a Policies row, so the worked example borrowed Domain Events — a row whose Purpose reads "Orange — outcomes" while a policy is violet. Making the tables the sole home of y values turned that omission load-bearing: an element with no row leaves nothing correct to pick. Policies sits at 1650, directly below the two event rows, since a policy reacts to an event and the Process Modeling table already groups the two on its Event-Command-Policy spine. What-if challenges and BC Contracts (outbound) shift down 250px to keep every adjacent gap at or above the minimum. Consumers reference these rows by name, never by coordinate, so the shift stays inside this table. Also restores the Read Model that headed the example's x=0 column, so the example again walks every row it touches. Co-authored-by: Claude Opus 5 (1M context) --- .../skills/simulation/reference/miro-integration.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/plugins/event-storming/skills/simulation/reference/miro-integration.md b/plugins/event-storming/skills/simulation/reference/miro-integration.md index 024966676e..d53d61a084 100644 --- a/plugins/event-storming/skills/simulation/reference/miro-integration.md +++ b/plugins/event-storming/skills/simulation/reference/miro-integration.md @@ -182,8 +182,9 @@ Persona 1 sits at the `y=0` timeline baseline. | Business Rules | 300 | Gray — invariants (stack at y=300, 550, 800) | | Domain Events | 1100 | Orange — outcomes | | Alternative outcomes | 1400 | Rejection/failure events | -| What-if challenges | 1700 | Red hot spots | -| BC Contracts (outbound) | 2000 | Published events | +| Policies | 1650 | Violet — reactive `Whenever X, do Y` | +| What-if challenges | 1950 | Red hot spots | +| BC Contracts (outbound) | 2250 | Published events | **Reading the layout:** every row's y comes from that phase's Y-Coordinate Table above — negative is up, positive is down, and the bolded row is the baseline. The @@ -194,11 +195,12 @@ item, independent of phase. A command and the actor that issues it share one x a differ only by row, so a single flow segment is a column per step: ``` +Read Model x=0 row: Read Models Actor x=0 row: Actors Command x=0 row: Commands Domain Event x=400 row: Domain Events (happy path) Event (alt) x=400 row: Alternative outcomes (rejection/failure) -Policy x=800 row: Domain Events (reactive — "whenever") +Policy x=800 row: Policies (reactive — "whenever") Next Command x=1200 row: Commands (triggered by policy) Next Event x=1600 row: Domain Events ```