X-BEIdeas · experiments · demos

Compose

How E2 and AGM might work together — each concept stands on its own; this page is the bridge between them.

Domain context from E2, architecture context from AGM in the repo. I’m exploring what a roundtrip looks like when you use both.

The sequence below is a sketch I’m trying to make reproducible — files, steps, and artifacts spelled out.

  1. 1

    Specify (E2)

    Workshop / board: model the domain. Export schema-valid `.storm.json`.

  2. 2

    Build (agents + human)

    Attach JSON as extra context in the IDE. Implement, test, review. Human stays the gate.

  3. 3

    Architecture trail (AGM)

    As-is / to-be, interfaces, decisions in the Markdown graph under docs/architecture/. Verify in a separate chat from the write session.

  4. 4

    Back into the spec (optional)

    Bounded contexts / events from the graph or code back into the board — or update the board and re-export. Pick a source of truth per project.

Still open

  • On conflict, what wins: board, code, or AGM docs?
  • Which `.storm.json` fields may agents write — and under what review?
  • How do we version bridge rules as examples grow?

Links