schematex 0.8.1 → 0.8.3

package/dist/{chunk-YWYWVKRB.js → chunk-S7GR77NY.js}

@@ -1,4 +1,4 @@
-import { parseResult, renderResult } from './chunk-J6AIKEVV.js';
+import { parseResult, renderResult } from './chunk-LM5X7ZNR.js';
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -347,7 +347,18 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use to propagate the consequences of an initiating event through a chain of barriers/safety functions and quantify each outcome's frequency \u2014 the inductive complement to a fault tree and the right wing of a bowtie. Header `eventtree`/`eta`; declare the initiating event with a frequency, the ordered functions with success/failure branch probabilities, and outcome rows with `s`/`f`/`*` patterns. The engine computes path frequency = f_initiating \xD7 \u03A0 branch-probabilities and flags the dominant sequence.",
     cluster: "risk-reliability",
     standard: "IEC 62502:2010 \xB7 NUREG/CR-2300 (PRA) \xB7 ISO 31010 Annex B; see 39-EVENT-TREE-STANDARD.md",
-    syntaxKey: "eventtree"
+    syntaxKey: "eventtree",
+    aliases: ["Event Tree Analysis", "ETA diagram", "event tree", "\u4E8B\u4EF6\u6811\u5206\u6790"],
+    keywords: [
+      "probabilistic risk assessment",
+      "PRA",
+      "safety function",
+      "accident sequence",
+      "barrier analysis",
+      "consequence analysis",
+      "nuclear safety",
+      "IEC 62502"
+    ]
   },
   {
     type: "fmea",
@@ -356,7 +367,25 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use to score and prioritise how each component/process step can fail \u2014 severity, occurrence, detection \u2014 and decide what to fix first. Header `fmea`; declare item/function \u2192 failure mode \u2192 effect (with `sev`) \u2192 cause (with `occ`) \u2192 controls (with `det`). The engine computes RPN = S\xD7O\xD7D and the AIAG-VDA Action Priority (High/Medium/Low), sorts the sheet, and colour-fills the RPN/AP cells by risk. Schematex's first table-shaped diagram.",
     cluster: "risk-reliability",
     standard: "AIAG-VDA FMEA Handbook (2019) \xB7 IEC 60812:2018 \xB7 SAE J1739 \xB7 MIL-STD-1629A; see 40-FMEA-STANDARD.md",
-    syntaxKey: "fmea"
+    syntaxKey: "fmea",
+    aliases: [
+      "FMEA",
+      "Failure Mode and Effects Analysis",
+      "FMECA",
+      "failure mode analysis",
+      "\u6545\u969C\u6A21\u5F0F\u4E0E\u5F71\u54CD\u5206\u6790"
+    ],
+    keywords: [
+      "RPN",
+      "risk priority number",
+      "Action Priority",
+      "AIAG-VDA",
+      "DFMEA",
+      "PFMEA",
+      "severity occurrence detection",
+      "reliability engineering",
+      "IEC 60812"
+    ]
   },
   // ── Systems thinking / stochastic ────────────────────────────
   {
@@ -366,7 +395,23 @@ var DIAGRAM_REGISTRY = [
     useWhen: 'Use for systems thinking / system dynamics: variables connected by `+`/`\u2212` causal links, where the engine detects feedback loops and labels each R (even number of negative links) or B (odd). Header `causalloop`/`cld`; write `A -> B : +` links and optional `loop R1 "name"` annotations and `delay` marks. Distinct from `sociogram` (social ties, no polarity) and `flowchart` (process steps).',
     cluster: "causality-analysis",
     standard: "Sterman, Business Dynamics (2000) \xB7 Meadows, Thinking in Systems; see 41-CAUSAL-LOOP-STANDARD.md",
-    syntaxKey: "causalloop"
+    syntaxKey: "causalloop",
+    aliases: [
+      "Causal Loop Diagram",
+      "CLD",
+      "feedback loop diagram",
+      "systems thinking diagram",
+      "\u56E0\u679C\u56DE\u8DEF\u56FE"
+    ],
+    keywords: [
+      "system dynamics",
+      "reinforcing loop",
+      "balancing loop",
+      "feedback loop",
+      "stock and flow",
+      "Sterman",
+      "Meadows"
+    ]
   },
   {
     type: "markov",
@@ -375,7 +420,22 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use to model a probabilistic state process (reliability/availability, queueing, regime models) where you want the long-run distribution or absorption answer, not just the picture. Header `markov`/`markovchain`; write `S1 -> S2 : 0.3` transitions (each state's out-edges sum to 1). The engine computes the stationary distribution, classifies states, and for absorbing chains the fundamental matrix. Sibling of `state` and `petri`.",
     cluster: "behavior-modeling",
     standard: "Norris, Markov Chains (1997) \xB7 Kemeny & Snell, Finite Markov Chains; see 42-MARKOV-CHAIN-STANDARD.md",
-    syntaxKey: "markov"
+    syntaxKey: "markov",
+    aliases: [
+      "Markov chain",
+      "Markov chain diagram",
+      "stochastic state transition diagram",
+      "\u9A6C\u5C14\u53EF\u592B\u94FE"
+    ],
+    keywords: [
+      "stationary distribution",
+      "stochastic process",
+      "transition matrix",
+      "transition probability",
+      "absorbing state",
+      "steady state",
+      "discrete-time"
+    ]
   },
   // ── Software / process engineering ───────────────────────────
   {
@@ -385,7 +445,23 @@ var DIAGRAM_REGISTRY = [
     useWhen: 'Use to visualise a git branching/merging history. Header `gitGraph`; ordered `commit`, `branch <name>`, `checkout <name>`, `merge <name>`, `cherry-pick id: "\u2026"`, with `commit id:/tag:/type: HIGHLIGHT|REVERSE`. Mermaid `gitGraph` syntax parity so LLM output is drop-in compatible. Commits sit on per-branch lanes ordered chronologically; merges join lanes.',
     cluster: "software-uml",
     standard: "Mermaid gitGraph syntax \xB7 git DAG model; see 43-GIT-GRAPH-STANDARD.md",
-    syntaxKey: "gitgraph"
+    syntaxKey: "gitgraph",
+    aliases: [
+      "Git commit graph",
+      "git graph",
+      "git branch diagram",
+      "branching diagram",
+      "Git \u63D0\u4EA4\u56FE"
+    ],
+    keywords: [
+      "branching strategy",
+      "git history",
+      "merge",
+      "cherry-pick",
+      "GitFlow",
+      "Mermaid gitGraph",
+      "commit history"
+    ]
   },
   {
     type: "epc",
@@ -394,7 +470,22 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use for ARIS-style business process modelling (SAP / enterprise BPM). Header `epc`; declare `event`, `function`, connectors `and`/`or`/`xor`, and the control flow between them. The engine validates strict event\u2194function alternation and connector legality (an event cannot be the source of an OR/XOR split). Distinct from `bpmn` and `flowchart` \u2014 a separate published standard with stricter rules.",
     cluster: "corporate-legal",
     standard: "ARIS / Keller, N\xFCttgens & Scheer (1992); see 44-EPC-STANDARD.md",
-    syntaxKey: "epc"
+    syntaxKey: "epc",
+    aliases: [
+      "Event-driven Process Chain",
+      "EPC diagram",
+      "ARIS EPC",
+      "\u4E8B\u4EF6\u9A71\u52A8\u8FC7\u7A0B\u94FE"
+    ],
+    keywords: [
+      "ARIS",
+      "business process modeling",
+      "SAP",
+      "BPM",
+      "process chain",
+      "enterprise architecture",
+      "Scheer"
+    ]
   },
   {
     type: "idef0",
@@ -403,7 +494,23 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use to model what a system/process does and its inputs/controls/outputs/mechanisms \u2014 systems engineering, defence/government process docs, enterprise architecture. Header `idef0`; declare `function` boxes and ICOM arrows (`input`/`control`/`output`/`mechanism`) plus box\u2192box flows that name the target ICOM side. The engine enforces ICOM placement and assigns node numbers, in a diagonal box staircase.",
     cluster: "project-management",
     standard: "FIPS PUB 183 (1993) \xB7 SADT (Ross); see 45-IDEF0-STANDARD.md",
-    syntaxKey: "idef0"
+    syntaxKey: "idef0",
+    aliases: [
+      "IDEF0",
+      "IDEF0 function model",
+      "SADT diagram",
+      "function model",
+      "ICOM diagram"
+    ],
+    keywords: [
+      "functional modeling",
+      "FIPS 183",
+      "systems engineering",
+      "activity model",
+      "ICOM",
+      "process model",
+      "enterprise architecture"
+    ]
   },
   {
     type: "threatmodel",
@@ -412,7 +519,25 @@ var DIAGRAM_REGISTRY = [
     useWhen: "Use for security threat modelling (Microsoft SDL / OWASP Threat Dragon workflow): DFD shapes (external entity, process, data store), labelled data flows, and `boundary` trust zones. Header `threatmodel`/`stride`. The engine maps each element type to its STRIDE categories (external = S,R; process = all six; store = T,I,D + conditional R for logs; flow = T,I,D) and accents flows crossing a trust boundary. Includes the DFD base notation (no separate `dfd` engine).",
     cluster: "network-infrastructure",
     standard: "Shostack, Threat Modeling (2014) STRIDE-per-element \xB7 Microsoft SDL \xB7 base DFD DeMarco/Yourdon; see 46-THREAT-MODEL-STRIDE-STANDARD.md + 31-DFD-STANDARD.md",
-    syntaxKey: "threatmodel"
+    syntaxKey: "threatmodel",
+    aliases: [
+      "Threat model",
+      "STRIDE diagram",
+      "DFD threat model",
+      "data flow diagram",
+      "DFD",
+      "\u5A01\u80C1\u5EFA\u6A21"
+    ],
+    keywords: [
+      "STRIDE",
+      "security threat modeling",
+      "Microsoft SDL",
+      "OWASP Threat Dragon",
+      "trust boundary",
+      "attack surface",
+      "application security",
+      "Shostack"
+    ]
   },
   {
     type: "welding",
@@ -421,7 +546,24 @@ var DIAGRAM_REGISTRY = [
     useWhen: 'Use to annotate a welded joint on an engineering drawing: a horizontal reference line, a leader arrow to the joint, and a weld-symbol glyph above (other side) / below (arrow side) with size, length-pitch, groove angle, root opening, contour + finish. Header `welding [standard: aws|iso-a|iso-b]`; one `joint "label" { arrow: \u2026 other: \u2026 around field tail: \u2026 }` block per joint. Full glyph catalog (fillet, all groove types, plug/slot, spot/seam, back/backing, surfacing, edge) + weld-all-around, field flag, and tail process note. Validates illegal type/side/dimension combinations.',
     cluster: "electrical-industrial",
     standard: "AWS A2.4:2020 \xB7 ISO 2553:2019; see 47-WELDING-SYMBOL-STANDARD.md",
-    syntaxKey: "welding"
+    syntaxKey: "welding",
+    aliases: [
+      "Welding symbols",
+      "weld symbol",
+      "welding callout",
+      "weld joint symbol",
+      "\u710A\u63A5\u7B26\u53F7"
+    ],
+    keywords: [
+      "AWS A2.4",
+      "ISO 2553",
+      "fillet weld",
+      "groove weld",
+      "weld notation",
+      "engineering drawing",
+      "fabrication",
+      "weld dimensions"
+    ]
   }
 ];
 var DIAGRAM_SINCE = {
@@ -3771,8 +3913,17 @@ var PROFILES = {
     type: "entity",
     header: 'entity-structure "Title"',
     mode: "legal entities + ownership edges",
-    forms: ['entity holdco "HoldCo" corp@US', 'entity opco "OpCo" llc@DE', "holdco -> opco : 100%"],
-    prefer: ["Use `entity` declarations before ownership edges.", "Keep legal form and jurisdiction explicit when known."],
+    forms: [
+      'entity holdco "HoldCo" corp@US',
+      'entity opco "OpCo" llc@DE',
+      "holdco -> opco : 100%",
+      'cluster "Group Name" [members: [holdco, opco]]'
+    ],
+    prefer: [
+      "Use `entity` declarations before ownership edges.",
+      "Keep legal form and jurisdiction explicit when known.",
+      'Group entities with `cluster "Name" [members: [id1, id2]]` \u2014 the members value MUST be a bracketed list.'
+    ],
     avoid: ["Avoid database schema terminology; use `erd` for tables and FKs."],
     repair: ["Unknown ownership endpoints need entity declarations."]
   },
@@ -4451,7 +4602,9 @@ function listDiagrams() {
     tagline: d.tagline,
     useWhen: d.useWhen,
     cluster: d.cluster,
-    standard: d.standard
+    standard: d.standard,
+    ...d.aliases ? { aliases: d.aliases } : {},
+    ...d.keywords ? { keywords: d.keywords } : {}
   }));
 }
 function getSyntax(type, opts = {}) {
@@ -4554,5 +4707,5 @@ function repairHint(type) {
 }
 
 export { DIAGRAM_REGISTRY, DIAGRAM_SINCE, getAllDiagramTypes, getDiagramMeta, getDiagramSince, getExamples, getSyntax, listDiagrams, renderDsl, resolveDiagramType, validateDsl };
-//# sourceMappingURL=chunk-YWYWVKRB.js.map
-//# sourceMappingURL=chunk-YWYWVKRB.js.map
+//# sourceMappingURL=chunk-S7GR77NY.js.map
+//# sourceMappingURL=chunk-S7GR77NY.js.map