create-yss-spec 2.1.5 → 2.1.6

package/template/.hermes/skills/drawio/references/docs/agent-diagrams.md

@@ -1,164 +0,0 @@
-# Agent & Memory Diagram Layouts
-
-YAML-first layout recipes for AI/agent system diagrams: agent architectures,
-memory architectures, mind maps, and timelines. These build on the semantic
-node and connector types documented in `design-system/shapes.md` (§Agentic /
-LLM System Vocabulary) and `design-system/connectors.md` (§Agentic / LLM Flow
-Semantics). Everything here is expressed as spec YAML — nodes, edges, modules,
-layout, and positions. There are no SVG coordinates, viewBox, or pixel drawing
-instructions; the converter owns rendering.
-
-## When to use
-
-The user is describing an LLM agent, a RAG pipeline, a memory subsystem
-(Mem0 / MemGPT style), a multi-agent system, or a tool-calling loop, and wants
-a diagram of how the pieces reason, retrieve, remember, and act. Triggers:
-"agent 架构图", "RAG 图", "记忆架构", "memory architecture", "multi-agent",
-"工具调用循环", "agentic".
-
-## Theme note
-
-Use `theme: arch-dark` as the default for these diagrams. The agentic
-connector palette (`control`, `memory_read`, `memory_write`, `async`,
-`feedback`) is defined in every bundled theme: color-coded in `arch-dark`,
-`tech-blue`, `nature`, and `dark`; monochrome with dash-pattern distinctions in
-`academic` and `high-contrast` (color is never the only carrier of meaning
-there). Per-edge `style.strokeColor` / `style.dashed` still overrides the theme
-when a one-off deviation is needed.
-
-## Node & edge vocabulary
-
-| Concept                | Node `type`    | Notes                                    |
-| ---------------------- | -------------- | ---------------------------------------- |
-| LLM / foundation model | `llm`          | rounded rect                             |
-| Agent / orchestrator   | `agent`        | hexagon — signals an active controller   |
-| Vector / embedding DB  | `vector_store` | cylinder                                 |
-| Short-term / working   | `memory`       | dashed rounded rect (dashed = ephemeral) |
-| Long-term store        | `database`     | solid cylinder (persistent)              |
-| Tool / function        | `tool`         | rounded rect                             |
-| API gateway / ingress  | `gateway`      | hexagon                                  |
-
-| Flow                     | Edge `type`    | Rendering (arch-dark)          |
-| ------------------------ | -------------- | ------------------------------ |
-| Main request/response    | `primary`      | solid gray, open head          |
-| Secondary/async data     | `data`         | dashed gray, open head         |
-| Trigger / control signal | `control`      | solid orange, open head        |
-| Read from store/memory   | `memory_read`  | solid green, open head         |
-| Write to store/memory    | `memory_write` | dashed green, open head        |
-| Async / non-blocking     | `async`        | dashed gray, open head         |
-| Iterative feedback loop  | `feedback`     | solid violet, open head        |
-
-Read and write to the same store share a hue and differ by dash — this is why
-memory diagrams read clearly even in grayscale. Always add a legend when two or
-more edge semantics appear (see below).
-
-## 1. Agent Architecture
-
-Model the agent as five conceptual layers, top-to-bottom or left-to-right:
-
-1. **Input** — user, query, trigger (`user`).
-2. **Agent core** — the reasoning loop / planner (`agent`).
-3. **Memory** — short-term context (`memory`, dashed) vs. long-term stores
-   (`database` / `vector_store`, solid). Keep the ephemeral/persistent contrast
-   visible by type, not by hand-set fills.
-4. **Tool** — tool calls, APIs, code execution, search (`tool`).
-5. **Output** — response, action, side effect (`user`).
-
-Express the layers with `layout: horizontal` (or `vertical`) and optionally a
-`module` per layer to draw a boundary. Route the main path with `primary`;
-trigger a tool or a retrieval with `control`; return a tool result or a
-re-plan signal with `feedback` to close the reasoning loop. A `feedback` edge
-back into the agent is the iterative-reasoning cue — the fireworks source drew
-this as a curved loop arc; here the typed `feedback` connector carries the same
-meaning. Antiparallel pairs (`agent → tool` control, `tool → agent` feedback)
-are auto-offset by the converter, so they stay legible.
-
-Keep a return edge from passing straight through an intermediate node: if the
-context return would cross a stacked node in the same column, route it from the
-nearest node in the sub-flow (for example `retriever → agent`) rather than from
-the deepest one (`store → agent`). See `examples/agentic-rag.yaml`.
-
-## 2. Memory Architecture (Mem0 / MemGPT style)
-
-The defining move is **separating the write path from the read path**:
-
-- Write path: `memory_write` (dashed green) from the memory manager into each
-  store — `store()` / `consolidate()` operations.
-- Read path: `memory_read` (solid green) from the stores into a
-  retrieve-and-rank step — `retrieve()` / `recall()` operations.
-
-Use operation names as edge labels (`store`, `recall`, `retrieve`,
-`consolidate`). Lay memory **tiers** as a vertical or left-to-right
-progression — Working → Short-term → Long-term → External — using `memory`
-(dashed, volatile) for the near tiers and `vector_store` / `database` (solid,
-persistent) for the far tiers. See `examples/mem0-memory-layer.yaml`.
-
-## 3. Mind Map / Concept Map
-
-Use `layout: star` for a single-level radial map: one hub node plus spokes.
-The engine places spokes in a ring around the central device, so it fits
-hub-and-spoke concept maps well.
-
-Limits: `star` is single-level. It does not lay out second-level branches — for
-a two-tier mind map either place the second-level nodes with explicit
-`position` bounds, or switch to `layout: hierarchical` / `vertical` and draw an
-ordinary tree. When the concept map is really a hierarchy (more than one level
-of nesting, ordered children), prefer a hierarchical layout over `star`.
-
-## 4. Timeline / Gantt
-
-There is no dedicated timeline engine; build one as a recipe from existing
-primitives:
-
-- Lay phases/tasks left-to-right with `layout: horizontal` (or explicit
-  `position` for exact columns), one node per phase/bar.
-- Encode categories with per-node `style.fillColor` (a color band per
-  category), or group related bars under a `module` swimlane.
-- Mark milestones with a `decision` node (diamond) or a `text` node placed at
-  the milestone's x position, labeled above the axis.
-- Connect sequential phases with `primary`; show a dependency with
-  `dependency`.
-
-This is a composition recipe, not a new layout mode — keep it to a handful of
-bars and lean on modules/colors for the category structure.
-
-## Pattern quick reference
-
-Ready-to-render specs live in `references/examples/`:
-
-| Pattern            | Example file                       | Key types                              |
-| ------------------ | ---------------------------------- | -------------------------------------- |
-| RAG Pipeline       | `rag-pipeline.yaml`                | `vector_store`, `memory_read`, `data`  |
-| Agentic RAG        | `agentic-rag.yaml`                 | `agent`, `tool`, `control`, `feedback` |
-| Mem0 Memory Layer  | `mem0-memory-layer.yaml`           | `memory_write`, `memory_read`, tiers   |
-| Multi-Agent        | `multi-agent-orchestration.yaml`   | `agent`, `control`, `async`            |
-| Tool Call Loop     | `tool-call-loop.yaml`              | `llm`, `tool`, `control`, `feedback`   |
-
-## Legend
-
-When two or more edge semantics appear, add a compact single `text` node that
-names each color/dash used, placed below the diagram with clearance:
-
-```yaml
-nodes:
-  - id: legend
-    label: "Legend:  gray = primary   orange = control   green = memory read   violet = feedback loop"
-    type: text
-    position: { x: 530, y: 620 }
-```
-
-`text` nodes render transparent (no fill, no border) with theme-appropriate
-font color, so the legend stays readable on the dark canvas.
-
-## Self-check
-
-Before delivering:
-
-1. `node scripts/cli.js <spec>.yaml <out>.svg --validate` reports no errors and
-   no overlap/label-clearance warnings.
-2. `node-crossings` and `edge-crossings` are 0 — a return/feedback edge must not
-   pass through an intermediate node body.
-3. Read and write connectors are visibly distinct (solid vs. dashed green).
-4. A legend is present whenever two or more edge semantics are used.
-5. Every edge is bound to node ids (no floating arrows); text nodes are
-   transparent and content-sized.

package/template/.hermes/skills/drawio/references/docs/ah-format.md

@@ -1,322 +0,0 @@
-> **DEPRECATED**: The A-H format is superseded by the YAML specification format.
-> See [specification.md](design-system/specification.md) for the current format.
-> The converter (`ah-to-drawio.js`) remains functional for backward compatibility.
-
-# A-H Format Reference
-
-A structured diagram specification format for deterministic, reproducible diagram generation.
-
-## Overview
-
-The A-H format is an 8-section specification that transforms text or images into standardized diagrams:
-
-```
-Input (Text/Image) → A-H Spec → Draw.io XML → Rendered Diagram
-```
-
-| Section | Purpose |
-|---------|---------|
-| **A** | Layout: canvas ratio, flow direction |
-| **B** | Modules: 1-4 logical groupings |
-| **C** | Nodes: ID and label for each node |
-| **D** | Edges: connections with relation types |
-| **E** | Groupings: phases or timelines |
-| **F** | Methods: tools, metrics, techniques |
-| **G** | Visual: colors, icons, emphasis |
-| **H** | Export: format recommendations |
-
----
-
-## Prompt Template
-
-```
-【角色】你是"结构化流程图架构师+信息抽取专家"。
-
-【领域】<<<指定领域：如 软件架构/商业流程/工业流程/教学设计/项目管理/通用 >>>
-
-【输入类型】<<<选择：文本 / 图片 / 图片+文本 >>>
-
-【输入内容】
-<<<在此粘贴文本或上传图片>>>
-
-【语言】<<<指定：中文 / English / 自动检测 >>>
-
-【唯一输出】仅输出一份【A–H绘图规格】；必须按A→H顺序；除A–H外不得输出任何文字。
-
-【硬规则（违者失败）】
-1) 只用输入内容明确包含的实体、步骤、流程、方法、指标、产出；严禁补充未写内容。
-2) 流程顺序从输入内容推断，遵循领域通用逻辑（如有歧义则按阅读顺序）。
-3) 模块≤4；每模块3–5节点；可合并概括但不得新增含义。
-4) 缺失信息标注"未提及"，不得推断或臆测。
-5) 节点Label使用指定语言的短语（≤14字符/单词）；Label不得含编号、括号或特殊符号。
-6) 节点ID仅用于连线（N1, N2...），不显示在图中。
-7) 连线关系限定：因果/并行/分支/反馈/依赖。
-8) 线型限定：实线箭头（主流程）/虚线箭头（数据流或弱关联）/T形线（约束或阻断，仅输入明确时用）。
-
-【工作流要求】先在内部完成"结构分析"和"草图设计"（不输出），再输出最终A–H。
-
-【A–H格式】
-A 总体布局：画布比例（如16:9）；主流程方向（上→下/左→右）；阅读顺序说明
-B 模块设置：模块1–4，每模块一句话描述其目的
-C 节点清单：逐条列出
-   模块X-步骤Y
-   ID: N1
-   Label: <短语>
-D 连线关系：逐条列出
-   N1→N2；关系：…；线型：…
-E 分组与阶段：如有分组/阶段/时间线则写明，无则写"未提及"
-F 方法与标签：技术方法、工具、指标等补充标签；无则写"未提及"
-G 视觉规范：模块配色方案；重点强调色；图标建议（根据领域适配）
-H 导出建议：推荐格式（PNG/SVG/drawio）；超限时的简化策略
-```
-
----
-
-## Domain Configurations
-
-### 软件架构 (Software Architecture)
-
-```
-【领域】软件架构
-【风格】专业
-【图标建议】服务器/数据库/API/客户端/消息队列/缓存/负载均衡
-【典型流程】用户请求→网关→服务→数据层→响应
-```
-
-### 商业流程 (Business Process)
-
-```
-【领域】商业流程
-【图标建议】用户/表单/审批/通知/存储/报表
-【典型流程】输入→处理→决策→输出→归档
-```
-
-### 工业流程 (Industrial Process)
-
-```
-【领域】工业流程
-【图标建议】传感器/控制器/执行器/数据库/监控屏/报警
-【典型流程】对象→采集→处理→控制→产出
-```
-
-### 科研流程 (Research Workflow)
-
-```
-【领域】科研流程
-【图标建议】样本/实验/数据/分析/模型/产出
-【典型流程】对象→采集→处理→分析/建模→产出
-【特殊规则】样本量、统计方法、伦理声明如有则标注
-```
-
-### 项目管理 (Project Management)
-
-```
-【领域】项目管理
-【图标建议】里程碑/任务/团队/交付物/风险/决策点
-【典型流程】启动→规划→执行→监控→收尾
-```
-
-### 教学设计 (Teaching Design)
-
-```
-【领域】教学设计
-【图标建议】学习目标/内容/活动/评估/反馈
-【典型流程】目标→内容→活动→评估→改进
-```
-
-### IEEE网络架构 (IEEE Network)
-
-```
-【领域】网络架构
-【风格】IEEE标准
-【图标建议】路由器(R)/交换机(SW)/防火墙(FW)/云/服务器
-【典型流程】核心层→汇聚层→接入层
-【特殊规则】使用正交连线；区分实线(物理)/虚线(逻辑)；黑白友好高对比度
-```
-
----
-
-## Quality Gates
-
-### Output Contract
-
-| Rule | Valid | Invalid |
-|------|-------|---------|
-| Section count | Exactly 8 (A–H) | Missing or extra sections |
-| Section order | A → B → C → D → E → F → G → H | Any other order |
-| Extra text | None | Preface like "好的，以下是..." or trailing notes |
-
-### Structure Constraints
-
-| Constraint | Limit | Failure Condition |
-|------------|-------|-------------------|
-| Module count | ≤ 4 | More than 4 modules |
-| Nodes per module | 3–5 | Fewer than 3 or more than 5 |
-| Missing info | "未提及" / "Not specified" | Inferred or guessed content |
-
-### Node Label Rules (Section C)
-
-| Rule | Valid Example | Invalid Example |
-|------|---------------|-----------------|
-| Language | 用户认证 / User Auth | Mixed without reason |
-| Length | ≤14 chars/words | 这是一个非常长的节点标签名称 |
-| No numbers | 数据处理 | N1 数据处理 |
-| No brackets | 数据清洗 | 数据清洗(ETL) |
-| No punctuation | 异常检测 | 数据清洗-去噪 |
-| No special symbols | 用户验证 | AI模型★ |
-
-### Edge Rules (Section D)
-
-| Rule | Valid | Invalid |
-|------|-------|---------|
-| Reference format | N1→N2 | 数据采集→数据处理 |
-| Relation values | 因果 / 并行 / 分支 / 反馈 / 依赖 | 连接 / 关联 / 其他 |
-| Line types | 实线箭头 / 虚线箭头 / T形线 | 双向箭头 / 波浪线 |
-
----
-
-## Regression Examples
-
-### ✅ PASS: Minimal Input
-
-**Input:**
-
-```
-【领域】通用
-【输入内容】
-收集用户反馈，整理分类后提交给产品团队，最终形成改进报告。
-```
-
-**Expected:**
-
-- 3 modules maximum (收集 → 处理 → 产出)
-- Simple labels: 反馈收集, 分类整理, 报告生成
-
-### ❌ FAIL: Extra Text
-
-**Invalid:**
-
-```
-好的，我来帮你生成A-H格式的图表规格：
-
-A 总体布局：...
-...
-H 导出建议：...
-
-希望这个规格对你有帮助！
-```
-
-**Reason:** Contains preface and trailing text.
-
-### ❌ FAIL: Labels with Prohibited Characters
-
-**Invalid:**
-
-```
-C 节点清单：
-  ID: N1
-  Label: N1-数据采集(传感器)
-```
-
-**Violations:** ID prefix "N1-" and brackets "(传感器)"
-
-**Correct:**
-
-```
-  Label: 数据采集
-```
-
-### ❌ FAIL: Edges with Labels Instead of IDs
-
-**Invalid:**
-
-```
-D 连线关系：
-  数据采集→数据清洗；关系：因果
-```
-
-**Correct:**
-
-```
-D 连线关系：
-  N1→N2；关系：因果；线型：实线箭头
-```
-
----
-
-## A-H to XML Conversion
-
-### Implementation
-
-The converter is located at `scripts/dsl/ah-to-drawio.js`:
-
-```javascript
-import { ahToDrawioXml, parseAh } from './scripts/dsl/ah-to-drawio.js'
-
-// Parse A-H text to structured data
-const parsed = parseAh(ahText)
-// { sections, modules, nodes, edges }
-
-// Convert directly to XML
-const xml = ahToDrawioXml(ahText, { page: { width: 1280, height: 720 } })
-```
-
-### What It Does
-
-- Parses sections A–H from plain text
-- Reads nodes from section C (`ID: N1`, `Label: ...`)
-- Reads edges from section D (`N1→N2 ...`)
-- Applies dashed style for `虚线` line type
-- Generates layout with module containers and stacked nodes
-- Validates and XML-escapes labels via `scripts/math` helpers
-- Emits numeric `mxCell id="..."` for draw.io compatibility
-
-### Limitations (By Design)
-
-- Layout is deterministic, not auto-optimized
-- Only uses IDs in edges; ignores labels in section D
-- Treats `T形线` as normal edge style
-- Logical IDs stored in `data-id` attribute
-
-### Example A-H Input
-
-```
-A 总体布局：16:9；左→右
-B 模块设置：
-模块1：计算
-模块2：评估
-C 节点清单：
-模块1-步骤1
-ID: N1
-Label: 线性模型 \(y=Wx+b\)
-模块2-步骤1
-ID: N2
-Label: $$\mathcal{L}=\sum_i (y_i-\hat y_i)^2$$
-D 连线关系：
-N1→N2；关系：因果；线型：实线箭头
-E 分组与阶段：未提及
-F 方法与标签：未提及
-G 视觉规范：未提及
-H 导出建议：drawio
-```
-
----
-
-## Quick Reference Card
-
-```
-┌─────────────────────────────────────────────────────────┐
-│  A–H Format Quick Validation                            │
-├─────────────────────────────────────────────────────────┤
-│  ✓ Exactly 8 sections (A→H order)                       │
-│  ✓ No text outside sections                             │
-│  ✓ Modules ≤ 4                                          │
-│  ✓ Nodes per module: 3–5                                │
-│  ✓ Labels: ≤14 chars, no symbols/numbers/brackets       │
-│  ✓ Edges: N1→N2 format only                             │
-│  ✓ Relations: 因果/并行/分支/反馈/依赖                    │
-│  ✓ Lines: 实线箭头/虚线箭头/T形线                        │
-│  ✓ Missing info: "未提及" (never infer)                  │
-│  ✓ All content from input only                          │
-└─────────────────────────────────────────────────────────┘
-```

package/template/.hermes/skills/drawio/references/docs/architecture-diagrams.md

@@ -1,159 +0,0 @@
-# Architecture Diagram Design Language
-
-Semantic color coding, boundary conventions, spacing discipline, and legend
-rules for system/software architecture diagrams rendered with the `arch-dark`
-theme.
-
-> **Attribution**: This design language is adapted from
-> [architecture-diagram-generator](https://github.com/Cocoon-AI/architecture-diagram-generator)
-> v1.1 (MIT License, Cocoon AI). See
-> `assets/licenses/architecture-diagram-generator-MIT.txt`. The original skill
-> emits HTML+SVG pages; this adaptation maps its palette and layout rules onto
-> the YAML-first `.drawio` pipeline.
-
-## When to use
-
-Software/system architecture, microservice maps, and cloud service diagrams
-that benefit from role-based color coding on a dark background. Not for
-network topology (use `ieee-network-diagrams.md`), publication figures (use
-the academic overlay), or light-background deliverables (use `tech-blue`).
-
-Set the theme in the spec:
-
-```yaml
-meta:
-  title: Order Platform Architecture
-  theme: arch-dark
-```
-
-## Role-to-type mapping
-
-Assign each component a role, then use the mapped node type. The `arch-dark`
-theme colors follow automatically — do not hand-set fills for these roles.
-
-| Role                  | Node type               | Fill      | Stroke    | Typical components                  |
-| --------------------- | ----------------------- | --------- | --------- | ----------------------------------- |
-| Frontend / client     | `user`                  | `#0E3A47` | `#22D3EE` | browsers, mobile apps, edge devices |
-| Backend service       | `service` / `process`   | `#064E3B` | `#34D399` | APIs, workers, gateways             |
-| Database / storage    | `database`              | `#3B2A63` | `#A78BFA` | SQL/NoSQL, object storage, caches   |
-| Cloud managed service | `cloud`                 | `#4A3410` | `#FBBF24` | CDN, serverless, managed queues     |
-| Message / event bus   | `queue`                 | `#4A2A12` | `#FB923C` | Kafka, RabbitMQ, event streams      |
-| External / generic    | `terminal` / `document` | `#1E293B` | `#94A3B8` | third-party systems, users' systems |
-| Security element      | module boundary         | `none`    | `#FB7185` | security groups, auth scopes        |
-
-Security is expressed as a dashed boundary (see below) or, for concrete auth
-components (identity provider), a `terminal` node connected with the rose
-`optional` connector.
-
-## Component labeling
-
-Two-line labels: component name first, technology + port second:
-
-```yaml
-nodes:
-  - id: api
-    label: "API Server\nFastAPI :8000"
-    type: service
-    position: { x: 320, y: 100 }
-```
-
-Per-line font styling is not supported (HTML in labels is rejected by
-validation); both lines render at the same size. Keep the second line short —
-technology name and port only. Visual hierarchy comes from role colors, not
-from label typography.
-
-## Boundary conventions
-
-Region/cloud boundaries and security groups are `modules` with style
-overrides. Members reference the module by id.
-
-```yaml
-nodes:
-  - id: api
-    label: "API Server\nFastAPI :8000"
-    type: service
-    position: { x: 320, y: 100 }
-    module: sg-api
-
-modules:
-  # Cloud region: large rounded, long amber dashes
-  - id: region
-    label: "AWS Region: us-west-2"
-    style:
-      fillColor: none
-      strokeColor: "#FBBF24"
-      dashed: true
-      dashPattern: "8 4"
-
-  # Security group: rose, short dashes
-  - id: sg-api
-    label: "sg-api :8000"
-    style:
-      fillColor: none
-      strokeColor: "#FB7185"
-      dashed: true
-      dashPattern: "4 4"
-```
-
-Keep `fillColor: none` on boundaries so connectors and members stay readable.
-
-## Connector semantics
-
-| Flow                      | Edge `type`  | Rendering                         |
-| ------------------------- | ------------ | --------------------------------- |
-| Primary request path      | `primary`    | solid `#94A3B8`, open head        |
-| Data/async flow           | `data`       | dashed `#64748B` (6 4)            |
-| Auth / security flow      | `optional`   | dashed rose `#FB7185` (5 5), open |
-| Infrastructure dependency | `dependency` | thin `#64748B`, diamond head      |
-
-Label protocols and ports on edges (`label: HTTPS`, `label: "JWT"`). Keep
-edges bound to node ids — never floating arrows (base rule 14).
-
-## Spacing discipline
-
-- Standard component footprint: about 120-160 wide, 60-64 tall. Let `size`
-  defaults apply unless replicating.
-- Module boundaries grow roughly 64 layout units above their topmost member's
-  center (padding plus label headroom). Keep the topmost in-module node at
-  `y >= 120` so the dashed boundary stays inside the canvas.
-- Minimum gap between stacked components: 40 layout units. Place message-bus
-  (`queue`) nodes **in the gap** between producer and consumer rows, never
-  overlapping either row.
-- Prefer auto layout (`layout: horizontal|vertical|hierarchical`) first; use
-  explicit `position` only when boundaries or flow direction demand it.
-- Run `--validate` and clear overlap and label-clearance warnings before
-  delivery.
-
-## Legend rules
-
-Build legends from small nodes plus `text` labels, one entry per role used in
-the diagram. Placement is strict:
-
-- The legend sits **outside every module boundary**, below the lowest one,
-  with at least 20 layout units of clearance.
-- Never place a legend inside a region/cluster boundary.
-
-```yaml
-nodes:
-  - id: legend-service
-    label: Backend
-    type: service
-    position: { x: 100, y: 560 }
-    size: small # size takes a preset name (small/medium/large/xl), not w/h
-  - id: legend-db
-    label: Database
-    type: database
-    position: { x: 220, y: 560 }
-    size: small
-```
-
-## Post-generation self-check
-
-Before reporting completion:
-
-1. Role colors match the mapping table (no hand-set fills drifting from it).
-2. Text readable on dark fills; no dark-on-dark labels.
-3. `--validate` reports no overlap or label-clearance warnings.
-4. Legend (if present) is below all module boundaries with clearance.
-5. Message-bus nodes sit in gaps, not on top of service rows.
-6. Exported SVG background is `#020617` (dark canvas is part of the design).