schematex 0.6.8 → 0.6.10

package/dist/{chunk-EDXDFKYO.cjs → chunk-DZGA25O5.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkAGBY7KLL_cjs = require('./chunk-AGBY7KLL.cjs');
+var chunk3YRYBTLG_cjs = require('./chunk-3YRYBTLG.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -2986,11 +2986,11 @@ var SYNTAX = {
   },
   "faulttree": {
     "title": "Fault Tree Analysis",
-    "content": '## 1. Your first diagram\n\nEvery document starts with the `faulttree` keyword (alias `fta`), an optional title, then a flat list of declarations wired by id:\n\n```\nfaulttree "Both pumps fail"\n  analysis: cutsets, probability\n  top T "Both redundant pumps fail" = AND(PA, PB)\n  basic PA "Pump A fails" p: 0.01\n  basic PB "Pump B fails" p: 0.01\n```\n\n`top` declares the single root event and the gate that produces it; `basic` declares a leaf component failure with a probability. The engine computes the minimal cut set `{PA, PB}` and P(top) = 1.0e-4. The DSL is **flat declaration + reference** (not nested by indentation) \u2014 a fault tree is a DAG, so a shared event is just referenced by id from several gates.\n\nHeader directives:\n\n- `analysis: cutsets, probability` \u2014 what to compute (also `pathsets`, `none`).\n- `prob: rare | mcub | exact` \u2014 the probability method (default `rare`, a conservative upper bound).\n- `layout: tb` \u2014 top-down textbook orientation. `bt` is reserved and currently reports a warning instead of changing the render.\n\n---\n\n## 2. Events\n\n```\ntop  T   "System fails"        = OR(A, B)\ngate G1  "Sub-fault"           = AND(A, B)\nbasic A  "Component A fails"   p: 0.01\nundeveloped EXT "External fire (not modelled)"\nhouse HX "Power on"            state: 1\n```\n\n- **`top`** \u2014 the one undesired event being analysed (rectangle, emphasised border). Exactly one is required.\n- **`gate`** \u2014 an intermediate event that is itself a gate output (rectangle).\n- **`basic`** \u2014 a primary component failure, the leaf that carries `p:` (circle).\n- **`undeveloped`** \u2014 an event not developed further (diamond); may carry `p:`.\n- **`house`** \u2014 a normally-expected event forced `state: 0` or `state: 1` (house glyph) \u2014 switches branches of the tree on/off.\n\nProbabilities accept decimals or scientific notation (`p: 0.004` or `p: 1e-6`); `p:` and `prob:` are interchangeable. An event with no probability is treated symbolically (cut sets still computed; P(top) reported as n/a).\n\n---\n\n## 3. Gates\n\n```\ntop  T1 = AND(A, B, C)            # all inputs occur\ntop  T2 = OR(A, B)                # at least one input occurs\ntop  T3 = XOR(A, B)               # exactly one (treated as OR for cut sets)\ntop  T4 = VOTING(2/3; A, B, C)    # at least k of n\ngate G1 = INHIBIT(A) if COND      # A occurs AND the condition holds\ngate G2 = PAND(A, B) order: A, B  # A then B (order rendered, AND for cut sets)\n```\n\nGates are drawn **output-up, inputs-down** (the mirror of a `logic` gate): AND is a flat-bottomed dome, OR/XOR/VOTING a shield, INHIBIT a hexagon. The conditioning event of an `INHIBIT`/`PAND` renders as an ellipse to the side. A gate may reference another gate or any event \u2014 and the same basic event may feed several gates (a repeated event).\n\n---\n\n## 4. Computed cut sets & probability\n\nThis is the differentiator. With `analysis: cutsets`, the engine runs **MOCUS**: AND gates grow the order of a cut set, OR gates multiply the number of cut sets, then idempotence (`A\u2227A=A`) and absorption (`X \u2286 Y \u21D2 drop Y`) minimise the result.\n\n- Each **minimal cut set** is boxed in red; an **order-1 cut set is a single point of failure** (strongest red, `data-spof`).\n- A **repeated event** (one basic event under several gates) is handled by absorption \u2014 the case a naive expander gets wrong.\n- **P(top)** is computed from per-event probabilities: `rare` (\u03A3 cut-set probs, default), `mcub` (1 \u2212 \u220F(1\u2212P)), or `exact` (inclusion-exclusion, which correctly de-duplicates a shared event). The method is shown next to the top event and noted in `<desc>`.\n- A `house state: 0` can make the top event unsatisfiable \u2014 reported as "no cut sets."\n\n---\n\n## 5. Repeated events\n\n```\nfaulttree "Safety function fails"\n  analysis: cutsets, probability\n  prob: exact\n  top T "Safety function fails" = OR(C1, C2)\n  gate C1 "Channel 1" = AND(S1, L1)\n  gate C2 "Channel 2" = AND(S2, L1)\n  basic S1 "Sensor 1 fails" p: 0.05\n  basic S2 "Sensor 2 fails" p: 0.05\n  basic L1 "Shared logic solver fails" p: 0.05\n```\n\n`L1` feeds both channels \u2014 it is drawn once per reference with a shared-event mark, but the cut-set engine treats every instance as one Boolean variable. Cut sets are `{S1, L1}` and `{S2, L1}`; `prob: exact` subtracts the overlap (L1 counted once over the union), giving 0.004875 rather than the rare-event 0.005.\n\n---\n\n## 6. Transfers\n\n```\ngate OVP "Sustained over-pressure" = INHIBIT(PUMP) if HEATER\ntransfer OVP -> "OVP-detail"\n```\n\nA `transfer ID -> "name"` draws the transfer-out triangle below an event whose development lives elsewhere; a matching `transfer "name" = gate_expr` defines that named subtree and is spliced in for cut-set computation. v0.1 resolves transfers in-document.\n\n---\n\n## 7. Validation\n\nThe parser fails fast with readable errors so the cut-set math is meaningful:\n\n- exactly one `top` is required (zero or several is an error);\n- a gate referencing an undeclared id reports the id by name;\n- cycles are rejected (a fault tree is a DAG);\n- a probability outside `[0, 1]`, a `VOTING k/n` with `k > n` or `n \u2260 input count`, or an `if` condition on a non-INHIBIT/PAND gate are all reported in plain English.\n\n---\n\n## 8. Theming\n\n`default` uses the house palette \u2014 soft slate-blue event boxes, **green gates** ("logic proceeds"), **red cut-set boxes** (the computed risk), blue probability numerals, a yellow house. `monochrome` reproduces the NUREG-0492 black-and-white textbook look, where the dome/shield shape (not colour) carries the gate type. All strokes/fills come from `ReliabilityTokens`; every element carries `data-*` (`data-cutset`, `data-spof`, `data-prob`, `data-gate`) so the computed analysis is inspectable downstream.'
+    "content": '## 1. Your first diagram\n\nEvery document starts with the `faulttree` keyword (alias `fta`), an optional title, then a flat list of declarations wired by id:\n\n```\nfaulttree "Both pumps fail"\n  analysis: cutsets, probability\n  top T "Both redundant pumps fail" = AND(PA, PB)\n  basic PA "Pump A fails" p: 0.01\n  basic PB "Pump B fails" p: 0.01\n```\n\n`top` declares the single root event and the gate that produces it; `basic` declares a leaf component failure with a probability. The engine computes the minimal cut set `{PA, PB}` and P(top) = 1.0e-4. The DSL is **flat declaration + reference** (not nested by indentation) \u2014 a fault tree is a DAG, so a shared event is just referenced by id from several gates.\n\nHeader directives:\n\n- `analysis: cutsets, probability` \u2014 what to compute (also `pathsets`, `none`).\n- `prob: rare | mcub | exact` \u2014 the probability method (default `rare`, a conservative upper bound).\n- `layout: tb | bt` \u2014 top-down (default) or bottom-up.\n\n---\n\n## 2. Events\n\n```\ntop  T   "System fails"        = OR(A, B)\ngate G1  "Sub-fault"           = AND(A, B)\nbasic A  "Component A fails"   p: 0.01\nundeveloped EXT "External fire (not modelled)"\nhouse HX "Power on"            state: 1\n```\n\n- **`top`** \u2014 the one undesired event being analysed (rectangle, emphasised border). Exactly one is required.\n- **`gate`** \u2014 an intermediate event that is itself a gate output (rectangle).\n- **`basic`** \u2014 a primary component failure, the leaf that carries `p:` (circle).\n- **`undeveloped`** \u2014 an event not developed further (diamond); may carry `p:`.\n- **`house`** \u2014 a normally-expected event forced `state: 0` or `state: 1` (house glyph) \u2014 switches branches of the tree on/off.\n\nProbabilities accept decimals or scientific notation (`p: 0.004` or `p: 1e-6`); `p:` and `prob:` are interchangeable. An event with no probability is treated symbolically (cut sets still computed; P(top) reported as n/a).\n\n---\n\n## 3. Gates\n\n```\ntop  T1 = AND(A, B, C)            # all inputs occur\ntop  T2 = OR(A, B)                # at least one input occurs\ntop  T3 = XOR(A, B)               # exactly one (treated as OR for cut sets)\ntop  T4 = VOTING(2/3; A, B, C)    # at least k of n\ngate G1 = INHIBIT(A) if COND      # A occurs AND the condition holds\ngate G2 = PAND(A, B) order: A, B  # A then B (order rendered, AND for cut sets)\n```\n\nGates are drawn **output-up, inputs-down** (the mirror of a `logic` gate): AND is a flat-bottomed dome, OR/XOR/VOTING a shield, INHIBIT a hexagon. The conditioning event of an `INHIBIT`/`PAND` renders as an ellipse to the side. A gate may reference another gate or any event \u2014 and the same basic event may feed several gates (a repeated event).\n\n---\n\n## 4. Computed cut sets & probability\n\nThis is the differentiator. With `analysis: cutsets`, the engine runs **MOCUS**: AND gates grow the order of a cut set, OR gates multiply the number of cut sets, then idempotence (`A\u2227A=A`) and absorption (`X \u2286 Y \u21D2 drop Y`) minimise the result.\n\n- Each **minimal cut set** is boxed in red; an **order-1 cut set is a single point of failure** (strongest red, `data-spof`).\n- A **repeated event** (one basic event under several gates) is handled by absorption \u2014 the case a naive expander gets wrong.\n- **P(top)** is computed from per-event probabilities: `rare` (\u03A3 cut-set probs, default), `mcub` (1 \u2212 \u220F(1\u2212P)), or `exact` (inclusion-exclusion, which correctly de-duplicates a shared event). The method is shown next to the top event and noted in `<desc>`.\n- A `house state: 0` can make the top event unsatisfiable \u2014 reported as "no cut sets."\n\n---\n\n## 5. Repeated events\n\n```\nfaulttree "Safety function fails"\n  analysis: cutsets, probability\n  prob: exact\n  top T "Safety function fails" = OR(C1, C2)\n  gate C1 "Channel 1" = AND(S1, L1)\n  gate C2 "Channel 2" = AND(S2, L1)\n  basic S1 "Sensor 1 fails" p: 0.05\n  basic S2 "Sensor 2 fails" p: 0.05\n  basic L1 "Shared logic solver fails" p: 0.05\n```\n\n`L1` feeds both channels \u2014 it is drawn once per reference with a shared-event mark, but the cut-set engine treats every instance as one Boolean variable. Cut sets are `{S1, L1}` and `{S2, L1}`; `prob: exact` subtracts the overlap (L1 counted once over the union), giving 0.004875 rather than the rare-event 0.005.\n\n---\n\n## 6. Transfers\n\n```\ngate OVP "Sustained over-pressure" = INHIBIT(PUMP) if HEATER\ntransfer OVP -> "OVP-detail"\n```\n\nA `transfer ID -> "name"` draws the transfer-out triangle below an event whose development lives elsewhere; a matching `transfer "name" = gate_expr` defines that named subtree and is spliced in for cut-set computation. v0.1 resolves transfers in-document.\n\n---\n\n## 7. Validation\n\nThe parser fails fast with readable errors so the cut-set math is meaningful:\n\n- exactly one `top` is required (zero or several is an error);\n- a gate referencing an undeclared id reports the id by name;\n- cycles are rejected (a fault tree is a DAG);\n- a probability outside `[0, 1]`, a `VOTING k/n` with `k > n` or `n \u2260 input count`, or an `if` condition on a non-INHIBIT/PAND gate are all reported in plain English.\n\n---\n\n## 8. Theming\n\n`default` uses the house palette \u2014 soft slate-blue event boxes, **green gates** ("logic proceeds"), **red cut-set boxes** (the computed risk), blue probability numerals, a yellow house. `monochrome` reproduces the NUREG-0492 black-and-white textbook look, where the dome/shield shape (not colour) carries the gate type. All strokes/fills come from `ReliabilityTokens`; every element carries `data-*` (`data-cutset`, `data-spof`, `data-prob`, `data-gate`) so the computed analysis is inspectable downstream.'
   },
   "bowtie": {
     "title": "Bowtie Risk Diagram",
-    "content": '## 1. Your first diagram\n\nEvery document starts with the `bowtie` keyword, an optional title, then the hazard, the top event, and the two wings:\n\n```\nbowtie\ntopevent "Loss of containment"\nthreat "Corrosion"\n  prevent "Inspection programme"\nconsequence "Release to atmosphere"\n  mitigate "Gas detection + ESD"\n```\n\n`topevent` declares the single knot at the centre (mandatory, exactly one). Each `threat` starts a left-wing line; each `consequence` ends a right-wing line. A barrier under a `threat` is **preventative** (`prevent`); under a `consequence` it is **mitigative** (`mitigate`). The diagram is laid out symmetrically about the knot \u2014 threats fan in from the left, consequences fan out to the right.\n\nThe DSL is **indentation-structured** and mirrors the CCPS 7-step build methodology: identify the hazard \u2192 the top event \u2192 the threats \u2192 the consequences \u2192 the preventative barriers \u2192 the mitigative barriers \u2192 the escalation factors.\n\nHeader directives (any order):\n\n- `layout: symmetric` \u2014 band model (default). `compact` is reserved and currently reports a warning instead of changing the render.\n- `legend: on | off | bottom | top` \u2014 the auto-derived colour legend (default on).\n\n---\n\n## 2. Hazard and top event\n\n```\nhazard "Working at height"\ntopevent "Person falls from height"\n```\n\n- **`hazard`** \u2014 the operation or material with the potential to cause harm: the *context* the bowtie is about (e.g. "Working at height", "Hydrocarbon under pressure"). Optional; renders as a header box above the knot with a tie-line down to it. At most one.\n- **`topevent`** \u2014 the moment control of the hazard is **lost** (e.g. "Loss of containment", "Person falls from height"). The knot of the bowtie, drawn as a green circle. **Mandatory, exactly one.**\n\nA hazard is a *thing/activity*, not a failure; the top event is the precise moment of *loss of control* \u2014 not a cause, and not yet a consequence.\n\n---\n\n## 3. Threats and consequences\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n\nconsequence "Fatality"\n  mitigate "Fall-arrest harness + lanyard"\n```\n\n- A **threat** is a credible cause that, *on its own*, could trigger the top event. Each threat is the start of one left-wing line, drawn as an orange box on the left edge.\n- A **consequence** is a credible outcome *of the top event* (not of the threat), drawn as a red box on the right edge.\n\nThreats and consequences may be declared in any interleaved order \u2014 the parser groups all left-wing blocks and all right-wing blocks regardless of sequence. A bowtie needs **at least one of each**: a one-wing diagram is a fault tree (see `faulttree`) or an event tree, not a bowtie.\n\n---\n\n## 4. Barriers (the controls in between)\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n  prevent "Temporary edge protection"\n  prevent "Spotter / banksman"\n```\n\nA **barrier** is a control that interrupts the threat \u2192 top-event path (preventative) or reduces the consequence after the top event (mitigative). Each is a grey box *on the line*. Chains are free length (1..n) \u2014 the wing simply extends.\n\n**Barrier order is declaration order**: the first declared is the **outermost** (closest to the threat/consequence, the first line of defence); the last declared is the **innermost** (closest to the knot). This matches the left-to-right reading of a real bowtie. Each barrier carries `data-order` (0 = outermost) and `data-side` (`prevent` / `mitigate`) for downstream interactivity.\n\nWhen chains differ in length, barriers are **centre-anchored**: the innermost barriers align in a neat column near the knot, and the threat/consequence boxes are ragged by chain depth \u2014 reading as defence-in-depth.\n\n---\n\n## 5. Escalation factors\n\n```\nthreat "Corrosion"\n  prevent "UT thickness inspection"\n    escalation "Inspection interval too long"\n      barrier "Risk-based inspection scheme"\n```\n\nAn **escalation factor** (or degradation factor) is a condition that *degrades a specific barrier\'s effectiveness* \u2014 e.g. "Edge protection not inspected", "Operator fatigue". It attaches to **one** barrier (not to the line) and drops vertically below it as an amber box, joined by a muted "degrades" connector.\n\nAn **escalation-factor barrier** is a control placed on the escalation factor itself \u2014 it protects the barrier from being degraded (e.g. a pre-use inspection regime). It nests one level deeper, under the escalation factor, and renders as a grey box below it.\n\nIndentation binds the nesting: `prevent`/`mitigate` at 2 spaces, `escalation` at 4, `barrier` at 6.\n\n---\n\n## 6. Correct by construction (the barrier rule set)\n\nBefore it draws a single shape, the engine validates the structural half of the CCPS/EI barrier rule set and **refuses to render** on failure \u2014 exactly as `prisma` refuses missing counts:\n\n- **Exactly one top event** \u2014 zero or several is an error.\n- **Every threat has \u2265 1 preventative barrier** \u2014 a bare threat is a Swiss-cheese cartoon, not a bowtie.\n- **Every consequence has \u2265 1 mitigative barrier** \u2014 the mirror rule.\n- **Every escalation factor is attached to a barrier** \u2014 it cannot float on a line or on the top event.\n- **At least one threat and one consequence** \u2014 a one-wing diagram is an FTA or an ETA.\n\nMessages name the offending element and the rule in plain English, e.g. *"Threat \'Corrosion\' has no preventative barrier \u2014 every threat must reach the top event through at least one barrier (CCPS/EI barrier rule). Add a `prevent` line under it."* This is what separates a real bowtie from a doodle. The engine does **not** judge whether a barrier is truly *effective* or *independent* \u2014 that is the analyst\'s qualitative judgement.\n\n---\n\n## 7. Bowtie vs fault tree\n\nA fully-developed bowtie *is* a fault tree glued to an event tree at the top event: the left wing read backwards is the fault tree whose top event is the bowtie\'s knot, and the right wing is the event tree that propagates it into consequences. Schematex keeps them as two engines because their use differs:\n\n- **`bowtie`** is qualitative and symmetric \u2014 the barrier inventory and the at-a-glance defence-in-depth story; no probability arithmetic.\n- **`faulttree`** is quantitative and Boolean \u2014 AND/OR gates, basic-event probabilities, minimal cut sets, a probability rollup.\n\nWhere you want the gate-level detail behind a single threat, draw a separate `faulttree`.\n\n---\n\n## 8. Theming\n\n`default` uses the recognised BowTieXP / bowtiemaster palette \u2014 **orange threats** (left), **grey barriers** on the line, a **green top-event disc** (centre knot), **red consequences** (right), **amber escalation factors** dropping below \u2014 mapped onto Schematex\'s semantic slots so it stays coherent with `prisma` / `pert` / `petri`. `monochrome` reproduces the regulator-print black-and-white look, where element distinction rides on shape/border + position (escalation factors get a dashed border, the knot a doubled ring) rather than colour. `dark` follows Catppuccin Mocha. All strokes/fills come from `BowtieTokens`; every element carries `data-*` (`data-role`, `data-side`, `data-line`, `data-order`, `data-barrier`) so the structure is inspectable downstream.'
+    "content": '## 1. Your first diagram\n\nEvery document starts with the `bowtie` keyword, an optional title, then the hazard, the top event, and the two wings:\n\n```\nbowtie\ntopevent "Loss of containment"\nthreat "Corrosion"\n  prevent "Inspection programme"\nconsequence "Release to atmosphere"\n  mitigate "Gas detection + ESD"\n```\n\n`topevent` declares the single knot at the centre (mandatory, exactly one). Each `threat` starts a left-wing line; each `consequence` ends a right-wing line. A barrier under a `threat` is **preventative** (`prevent`); under a `consequence` it is **mitigative** (`mitigate`). The diagram is laid out symmetrically about the knot \u2014 threats fan in from the left, consequences fan out to the right.\n\nThe DSL is **indentation-structured** and mirrors the CCPS 7-step build methodology: identify the hazard \u2192 the top event \u2192 the threats \u2192 the consequences \u2192 the preventative barriers \u2192 the mitigative barriers \u2192 the escalation factors.\n\nHeader directives (any order):\n\n- `layout: symmetric | compact` \u2014 band model (default `symmetric`).\n- `legend: on | off | bottom | top` \u2014 the auto-derived colour legend (default on).\n\n---\n\n## 2. Hazard and top event\n\n```\nhazard "Working at height"\ntopevent "Person falls from height"\n```\n\n- **`hazard`** \u2014 the operation or material with the potential to cause harm: the *context* the bowtie is about (e.g. "Working at height", "Hydrocarbon under pressure"). Optional; renders as a header box above the knot with a tie-line down to it. At most one.\n- **`topevent`** \u2014 the moment control of the hazard is **lost** (e.g. "Loss of containment", "Person falls from height"). The knot of the bowtie, drawn as a green circle. **Mandatory, exactly one.**\n\nA hazard is a *thing/activity*, not a failure; the top event is the precise moment of *loss of control* \u2014 not a cause, and not yet a consequence.\n\n---\n\n## 3. Threats and consequences\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n\nconsequence "Fatality"\n  mitigate "Fall-arrest harness + lanyard"\n```\n\n- A **threat** is a credible cause that, *on its own*, could trigger the top event. Each threat is the start of one left-wing line, drawn as an orange box on the left edge.\n- A **consequence** is a credible outcome *of the top event* (not of the threat), drawn as a red box on the right edge.\n\nThreats and consequences may be declared in any interleaved order \u2014 the parser groups all left-wing blocks and all right-wing blocks regardless of sequence. A bowtie needs **at least one of each**: a one-wing diagram is a fault tree (see `faulttree`) or an event tree, not a bowtie.\n\n---\n\n## 4. Barriers (the controls in between)\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n  prevent "Temporary edge protection"\n  prevent "Spotter / banksman"\n```\n\nA **barrier** is a control that interrupts the threat \u2192 top-event path (preventative) or reduces the consequence after the top event (mitigative). Each is a grey box *on the line*. Chains are free length (1..n) \u2014 the wing simply extends.\n\n**Barrier order is declaration order**: the first declared is the **outermost** (closest to the threat/consequence, the first line of defence); the last declared is the **innermost** (closest to the knot). This matches the left-to-right reading of a real bowtie. Each barrier carries `data-order` (0 = outermost) and `data-side` (`prevent` / `mitigate`) for downstream interactivity.\n\nWhen chains differ in length, barriers are **centre-anchored**: the innermost barriers align in a neat column near the knot, and the threat/consequence boxes are ragged by chain depth \u2014 reading as defence-in-depth.\n\n---\n\n## 5. Escalation factors\n\n```\nthreat "Corrosion"\n  prevent "UT thickness inspection"\n    escalation "Inspection interval too long"\n      barrier "Risk-based inspection scheme"\n```\n\nAn **escalation factor** (or degradation factor) is a condition that *degrades a specific barrier\'s effectiveness* \u2014 e.g. "Edge protection not inspected", "Operator fatigue". It attaches to **one** barrier (not to the line) and drops vertically below it as an amber box, joined by a muted "degrades" connector.\n\nAn **escalation-factor barrier** is a control placed on the escalation factor itself \u2014 it protects the barrier from being degraded (e.g. a pre-use inspection regime). It nests one level deeper, under the escalation factor, and renders as a grey box below it.\n\nIndentation binds the nesting: `prevent`/`mitigate` at 2 spaces, `escalation` at 4, `barrier` at 6.\n\n---\n\n## 6. Correct by construction (the barrier rule set)\n\nBefore it draws a single shape, the engine validates the structural half of the CCPS/EI barrier rule set and **refuses to render** on failure \u2014 exactly as `prisma` refuses missing counts:\n\n- **Exactly one top event** \u2014 zero or several is an error.\n- **Every threat has \u2265 1 preventative barrier** \u2014 a bare threat is a Swiss-cheese cartoon, not a bowtie.\n- **Every consequence has \u2265 1 mitigative barrier** \u2014 the mirror rule.\n- **Every escalation factor is attached to a barrier** \u2014 it cannot float on a line or on the top event.\n- **At least one threat and one consequence** \u2014 a one-wing diagram is an FTA or an ETA.\n\nMessages name the offending element and the rule in plain English, e.g. *"Threat \'Corrosion\' has no preventative barrier \u2014 every threat must reach the top event through at least one barrier (CCPS/EI barrier rule). Add a `prevent` line under it."* This is what separates a real bowtie from a doodle. The engine does **not** judge whether a barrier is truly *effective* or *independent* \u2014 that is the analyst\'s qualitative judgement.\n\n---\n\n## 7. Bowtie vs fault tree\n\nA fully-developed bowtie *is* a fault tree glued to an event tree at the top event: the left wing read backwards is the fault tree whose top event is the bowtie\'s knot, and the right wing is the event tree that propagates it into consequences. Schematex keeps them as two engines because their use differs:\n\n- **`bowtie`** is qualitative and symmetric \u2014 the barrier inventory and the at-a-glance defence-in-depth story; no probability arithmetic.\n- **`faulttree`** is quantitative and Boolean \u2014 AND/OR gates, basic-event probabilities, minimal cut sets, a probability rollup.\n\nWhere you want the gate-level detail behind a single threat, draw a separate `faulttree`.\n\n---\n\n## 8. Theming\n\n`default` uses the recognised BowTieXP / bowtiemaster palette \u2014 **orange threats** (left), **grey barriers** on the line, a **green top-event disc** (centre knot), **red consequences** (right), **amber escalation factors** dropping below \u2014 mapped onto Schematex\'s semantic slots so it stays coherent with `prisma` / `pert` / `petri`. `monochrome` reproduces the regulator-print black-and-white look, where element distinction rides on shape/border + position (escalation factors get a dashed border, the knot a doubled ring) rather than colour. `dark` follows Catppuccin Mocha. All strokes/fills come from `BowtieTokens`; every element carries `data-*` (`data-role`, `data-side`, `data-line`, `data-order`, `data-barrier`) so the structure is inspectable downstream.'
   }
 };
 
@@ -3639,7 +3639,7 @@ function getExamples(type, opts = {}) {
 function validateDsl(type, dsl) {
   const resolvedType = type ? resolveDiagramType(type) : void 0;
   const config = type ? { type: resolvedType ?? type } : void 0;
-  const result = chunkAGBY7KLL_cjs.parseResult(dsl, config);
+  const result = chunk3YRYBTLG_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -3665,7 +3665,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunkAGBY7KLL_cjs.renderResult(dsl, config);
+  const result = chunk3YRYBTLG_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -3718,5 +3718,5 @@ exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.resolveDiagramType = resolveDiagramType;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-EDXDFKYO.cjs.map
-//# sourceMappingURL=chunk-EDXDFKYO.cjs.map
+//# sourceMappingURL=chunk-DZGA25O5.cjs.map
+//# sourceMappingURL=chunk-DZGA25O5.cjs.map