feat(baoyu-diagram): add architecture enrichment and structural layout patterns

This commit is contained in:
Jim Liu 宝玉
2026-04-14 11:32:55 -05:00
parent dcd0f81433
commit acbcf19ba2
7 changed files with 322 additions and 3 deletions
@@ -4,6 +4,21 @@ Load this file when the prompt asks about **network infrastructure**: "where do
Sub-pattern for diagrams whose subject is **where the wires go** — which devices sit where, which security zones contain them, which links are wired vs wireless. The structural diagram type is the right home for this (devices are containers, zones are outer containers, cables are arrows), but topology drawings have some conventions of their own.
## Domain color conventions
When a structural or network diagram has 3+ component categories, these conventional ramp assignments help the reader parse component types at a glance. These are **suggestions**, not hard rules — the ≤2 ramp constraint from `design-system.md` still applies for simple diagrams with only 12 categories.
| Component domain | Suggested ramp | Rationale |
|--------------------|---------------|----------------------------------------------|
| Frontend / Client | teal | cool, user-facing |
| Backend / API | green | processing, data transformation |
| Database / Storage | purple | depth, persistence |
| Cloud / Infra | amber | external boundary, warning-adjacent |
| Security / Auth | coral | attention, trust boundary |
| External / Generic | gray | neutral, not categorized |
When a diagram uses ≥3 of these, include a one-line legend strip at the bottom mapping colors to categories. When the diagram is simple enough to stay within 2 ramps, prefer the semantic pairing from `design-system.md` over these domain conventions.
## When to use it
- The reader's question is *"what is connected to what, and across which boundary"*, not *"what happens when a request arrives"* (that's a sequence diagram).
@@ -63,6 +78,23 @@ Two distinct link styles, both already in the template:
Place the legend at the bottom of the canvas, 20px above the bottom edge, aligned with the subject matter above it.
## Security zone containers
When a network diagram includes explicit trust boundaries (security groups, VPNs, firewalls-as-perimeters), use a **coral-tinted dashed container** to distinguish security zones from structural zones. This gives the reader an immediate visual signal: gray dashed = organizational grouping, coral dashed = trust boundary.
```svg
<rect x="60" y="100" width="560" height="160" rx="12" fill="none"
stroke-dasharray="4 4" class="arr-coral"/>
<rect class="c-coral" x="60" y="92" width="120" height="16" rx="8"/>
<text class="ts" x="120" y="104" text-anchor="middle">Trust boundary</text>
```
The coral container uses `class="arr-coral"` instead of `class="arr-alt"` — both are dashed, but `arr-coral` carries the semantic color. The pill label uses `class="c-coral"` for matching fill/stroke.
Typical security zone labels: *Security group*, *Trust boundary*, *VPN tunnel*, *Private subnet*, *Encrypted zone*, *DMZ* (when DMZ is drawn as a security boundary rather than an organizational tier).
When mixing structural zones (gray) and security zones (coral) in the same diagram, add a legend entry for the coral dash: `[- -] Trust boundary` alongside the structural zone entries.
## Tiered top-down layout
Network topology almost always reads top-down because the conventional mental model is *"traffic flows from the public internet down into the protected core"*. Lay out the zones vertically, one tier per row: