Problem
prose compose needs to help an architect choose a system shape after understanding purpose, desired render, state, authority, and failure constraints. The repository already contains executable coordination patterns and examples of reactive, event-mediated, and hybrid systems, but they are spread across different architectural levels and lack a coherent selection surface.
Flattening everything into std/patterns would mix executable coordination with lifecycle, state, and integration guidance.
Desired property
Compose can progressively disclose plausible topology profiles using a short fit statement and a self-evident labeled diagram, then load detailed guidance only for relevant candidates. Profiles can be selected independently for named regions and lower into existing call, pattern:, and Requires/Maintains mechanisms.
Smallest plausible change
Add a design-time std/topologies catalog separate from executable std/patterns. Each profile should define context signals and counter-signals, desired render/state model, likely Contract boundaries, failure/cost tradeoffs, compatible nested profiles, lowering mechanisms, and canonical examples.
Use labeled visual thumbnails such as [Research] -> [Draft] -> [Review]; do not introduce opaque A/B/C notation or runtime semantics for profile annotations.
Initial profiles should cover pipeline, fan-out/fan-in, maintained/reactive projection, event channel, and obligation network. Treat hybrid as explicit regional composition rather than its own catch-all profile.
Alternatives
- Expand
std/patterns into a mixed executable/design catalog.
- Keep the knowledge embedded only in Compose.
- Add first-class topology syntax now.
The design-time catalog is preferred until repeated programs demonstrate missing runtime semantics.
Problem
prose composeneeds to help an architect choose a system shape after understanding purpose, desired render, state, authority, and failure constraints. The repository already contains executable coordination patterns and examples of reactive, event-mediated, and hybrid systems, but they are spread across different architectural levels and lack a coherent selection surface.Flattening everything into
std/patternswould mix executable coordination with lifecycle, state, and integration guidance.Desired property
Compose can progressively disclose plausible topology profiles using a short fit statement and a self-evident labeled diagram, then load detailed guidance only for relevant candidates. Profiles can be selected independently for named regions and lower into existing
call,pattern:, andRequires/Maintainsmechanisms.Smallest plausible change
Add a design-time
std/topologiescatalog separate from executablestd/patterns. Each profile should define context signals and counter-signals, desired render/state model, likely Contract boundaries, failure/cost tradeoffs, compatible nested profiles, lowering mechanisms, and canonical examples.Use labeled visual thumbnails such as
[Research] -> [Draft] -> [Review]; do not introduce opaqueA/B/Cnotation or runtime semantics for profile annotations.Initial profiles should cover pipeline, fan-out/fan-in, maintained/reactive projection, event channel, and obligation network. Treat hybrid as explicit regional composition rather than its own catch-all profile.
Alternatives
std/patternsinto a mixed executable/design catalog.The design-time catalog is preferred until repeated programs demonstrate missing runtime semantics.