schematex 0.9.4 → 0.9.5

package/dist/{chunk-TX3YWZZX.cjs → chunk-7EWP4OD7.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkGTCAJPQR_cjs = require('./chunk-GTCAJPQR.cjs');
+var chunkQ7CWX6HA_cjs = require('./chunk-Q7CWX6HA.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -389,6 +389,34 @@ var DIAGRAM_REGISTRY = [
       "IEC 60812"
     ]
   },
+  {
+    type: "rbd",
+    name: "Reliability Block Diagram (RBD)",
+    tagline: "The success-logic diagram that computes its own system reliability \u2014 series/parallel/k-of-n reduction, Birnbaum importance, and single-point-of-failure detection.",
+    useWhen: 'Use to model whether a system *works* from the reliability of its components, and to compute the overall figure \u2014 RAMS analysis, redundancy/high-availability design, fault-tolerance trade studies. Header `rbd`; nest `series { \u2026 }`, `parallel { \u2026 }`, and `kofn k/n { \u2026 }` success-logic groups around `block ID "Label" R=0.99` leaves (`p=0.01` failure prob or `R=99%` also accepted). The engine computes system reliability (\u220F for series, 1\u2212\u220F(1\u2212R\u1D62) for parallel, exact k-of-n), the Birnbaum reliability-importance of every block, and flags blocks whose failure alone fails the system (SPOF, drawn in red). Sibling of fault tree (\xA737) in the risk-reliability cluster.',
+    cluster: "risk-reliability",
+    standard: "IEC 61078:2016 \xB7 MIL-HDBK-338B; see 50-RBD-STANDARD.md",
+    syntaxKey: "rbd",
+    aliases: [
+      "RBD",
+      "Reliability Block Diagram",
+      "reliability diagram",
+      "availability block diagram",
+      "\u53EF\u9760\u6027\u6846\u56FE"
+    ],
+    keywords: [
+      "IEC 61078",
+      "system reliability",
+      "redundancy",
+      "series parallel",
+      "k-out-of-n",
+      "high availability",
+      "RAMS",
+      "Birnbaum importance",
+      "single point of failure",
+      "fault tolerance"
+    ]
+  },
   // ── Systems thinking / stochastic ────────────────────────────
   {
     type: "causalloop",
@@ -692,7 +720,9 @@ var DIAGRAM_SINCE = {
   // 0.9.3
   floorplan: "0.9.3",
   // 0.9.4 — multi-sport playbook (football X&O / basketball / soccer)
-  playbook: "0.9.4"
+  playbook: "0.9.4",
+  // 0.9.5 — reliability block diagram (IEC 61078)
+  rbd: "0.9.5"
 };
 function getDiagramSince(type) {
   const resolved = resolveDiagramType(type);
@@ -3453,6 +3483,114 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": "prisma\nmode: 2020-single\ntitle: Effect of exercise on chronic low-back pain \u2014 SR\n\nidentification:\n  databases:\n    n: 1418\n    sources: PubMed=600, Embase=450, Cochrane=184, Web of Science=184\n    duplicates-removed: 318\n\nscreening:\n  records-screened: 1100\n  excluded:\n    n: 870\n    reasons: irrelevant title=750, non-English=120\n\neligibility:\n  full-text-assessed: 230\n  excluded:\n    n: 195\n    reasons: wrong population=80, wrong intervention=60, wrong outcome=55\n\nincluded:\n  studies: 35\n  reports: 38",
     "notes": '## Scenario\n\nA research librarian produces the PRISMA 2020 flow diagram for a Cochrane review submission. The journal **requires** the diagram in the exact four-row structure \u2014 Identification \u2192 Screening \u2192 Eligibility \u2192 Included \u2014 with the count `(n = \u2026)` shown in every box and the excluded boxes itemizing reasons. With the dedicated `prisma` engine the librarian writes only counts and reasons; the rigid layout, the "Records removed before screening" side-box, and the exclusion side-boxes are produced automatically and are correct by construction.\n\n## Annotation key\n\n- **`mode: 2020-single`** \u2014 one Identification column (databases & registers). Use `mode: 2020-dual` to add the "other methods" column.\n- **`identification.databases`** \u2014 `n:` is the mandatory total; `sources:` renders the per-database breakdown; `duplicates-removed:` splits out into the right-column "Records removed before screening" box automatically.\n- **`screening` / `eligibility` `excluded:` blocks** \u2014 each has its own `n:` total and an optional `reasons:` breakdown rendered in a side-box to the right, connected by a horizontal arrow.\n- **`included.studies` / `reports`** \u2014 one study can yield several reports, so both counts render.\n\n## How to read\n\nTop to bottom mirrors the PRISMA 2020 template exactly. The left capsule bands label the three canonical stages; the orange bar spans the Identification column group. Counts reconcile across stages (1418 \u2212 318 = 1100 screened; 1100 \u2212 870 = 230 assessed; 230 \u2212 195 = 35 included) \u2014 the engine warns if they don\'t.\n\n## Standard reference\n\nPage MJ, McKenzie JE, Bossuyt PM, et al. *The PRISMA 2020 statement: an updated guideline for reporting systematic reviews.* BMJ 2021;372:n71. Template: [prisma-statement.org/prisma-2020-flow-diagram](https://www.prisma-statement.org/prisma-2020-flow-diagram).'
   },
+  {
+    "slug": "rbd-data-center-tier-iii",
+    "diagram": "rbd",
+    "title": "Data-center availability (Tier III power, cooling, network, storage)",
+    "description": "A four-stage reliability block diagram for a Tier III data center \u2014 dual-source power (utility in parallel with a generator-plus-ATS chain), N+1 (2-of-3) CRAC cooling, dual core switches, and mirrored storage. The engine reduces the whole nested structure to one availability figure.",
+    "standard": "IEC 61078 / Uptime Institute Tier III",
+    "tags": [
+      "rbd",
+      "reliability",
+      "availability",
+      "data-center",
+      "redundancy",
+      "n-plus-1",
+      "k-of-n",
+      "series-parallel"
+    ],
+    "complexity": 4,
+    "featured": true,
+    "dsl": 'rbd "Data Center Tier III Availability"\n  series {\n    parallel {\n      block UTIL "Utility feed" R=0.999\n      series {\n        block GEN "Diesel generator" R=0.98\n        block ATS "Transfer switch" R=0.995\n      }\n    }\n    kofn 2/3 {\n      block CRAC1 "CRAC unit 1" R=0.97\n      block CRAC2 "CRAC unit 2" R=0.97\n      block CRAC3 "CRAC unit 3" R=0.97\n    }\n    parallel {\n      block SW1 "Core switch A" R=0.995\n      block SW2 "Core switch B" R=0.995\n    }\n    parallel {\n      block ST1 "Storage node A" R=0.99\n      block ST2 "Storage node B" R=0.99\n    }\n  }',
+    "notes": "## What this shows\n\nA realistic Tier III topology where the whole facility is a **series** of four subsystems, each internally redundant. The **power** stage is the interesting one: the utility feed runs in **parallel** with a backup *chain* \u2014 a generator that only helps if its transfer switch also works (a nested `series`). Cooling is **N+1** (`2-of-3` CRAC units), and both the network and storage tiers are mirrored pairs.\n\n**The engine reduces the nesting to one number.** It rolls the generator chain (`0.98 \xB7 0.995`) into the power parallel, evaluates the 2-of-3 cooling exactly, and multiplies the four series stages to a **facility availability of \u2248 0.9972**. No single point of failure survives \u2014 every stage has redundancy \u2014 and the Birnbaum importance ranks which subsystem to harden first. This is the kind of nested success logic a generic diagram tool draws but never computes."
+  },
+  {
+    "slug": "rbd-dual-channel-safety",
+    "diagram": "rbd",
+    "title": "Dual-channel safety system (redundant chains)",
+    "description": "A reliability block diagram of a 1-out-of-2 safety instrumented function \u2014 two independent sensor\u2192logic\u2192actuator channels in parallel, each a series chain. Shows how a parallel of series strings removes every single point of failure.",
+    "standard": "IEC 61078",
+    "tags": [
+      "rbd",
+      "reliability",
+      "safety",
+      "redundancy",
+      "1oo2",
+      "series-parallel"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'rbd "Dual-channel trip (1oo2)"\n  parallel {\n    series {\n      block S1 "Sensor A" R=0.97\n      block L1 "Logic A" R=0.995\n      block V1 "Valve A" R=0.98\n    }\n    series {\n      block S2 "Sensor B" R=0.97\n      block L2 "Logic B" R=0.995\n      block V2 "Valve B" R=0.98\n    }\n  }',
+    "notes": "## What this shows\n\nA **1-out-of-2 (1oo2)** safety architecture: two complete sensor\u2192logic\u2192valve channels run in parallel, so the trip still fires if either channel works end-to-end. Each channel is itself a **series** chain \u2014 a channel needs all three of its elements.\n\n**Redundancy removes the single points of failure.** Each channel alone has reliability `0.97\xB70.995\xB70.98 \u2248 0.946`; in parallel the system reaches `1 \u2212 (1\u22120.946)\xB2 \u2248 0.997`. Because no single block's failure drops the system to zero, the engine reports **no single point of failure** \u2014 the structural goal of a redundant safety function, proven by computation rather than asserted."
+  },
+  {
+    "slug": "rbd-flight-control",
+    "diagram": "rbd",
+    "title": "Fly-by-wire flight control (triple-redundant)",
+    "description": "A reliability block diagram of a fly-by-wire flight-control system \u2014 2-of-3 voting flight-control computers, triple-redundant hydraulics, and dual electrical buses, all in series. The engine computes the six-nines-class system reliability the architecture is designed to hit.",
+    "standard": "IEC 61078 / ARP4761",
+    "tags": [
+      "rbd",
+      "reliability",
+      "aerospace",
+      "fly-by-wire",
+      "redundancy",
+      "k-of-n",
+      "2oo3",
+      "triple-redundant"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'rbd "Fly-by-wire Flight Control"\n  series {\n    kofn 2/3 {\n      block FCC1 "Flight computer 1" R=0.9995\n      block FCC2 "Flight computer 2" R=0.9995\n      block FCC3 "Flight computer 3" R=0.9995\n    }\n    parallel {\n      block HYDG "Hydraulics green" R=0.998\n      block HYDB "Hydraulics blue" R=0.998\n      block HYDY "Hydraulics yellow" R=0.998\n    }\n    parallel {\n      block AC1 "AC bus 1" R=0.999\n      block AC2 "AC bus 2" R=0.999\n    }\n  }',
+    "notes": `## What this shows
+
+A textbook fly-by-wire architecture, the kind certified under ARP4761: **2-out-of-3** voting flight-control computers (a single computer can fail or disagree without losing control), **three independent hydraulic systems** (the green/blue/yellow split of a modern airliner), and **dual electrical buses** \u2014 all in **series** because the aircraft needs computing, hydraulics, and power simultaneously.
+
+**The architecture's whole point is a number, and the engine computes it.** Each subsystem is driven so close to 1 that the product still lands at a system reliability of **\u2248 0.999998** \u2014 and Schematex prints the nines rather than rounding to "1", because in this domain the nines *are* the answer. No single point of failure remains, which is exactly the design intent the diagram now proves rather than merely asserts.`
+  },
+  {
+    "slug": "rbd-redundant-server",
+    "diagram": "rbd",
+    "title": "Redundant server reliability (series + parallel + k-of-n)",
+    "description": "A computed reliability block diagram for a server \u2014 a single power supply in series with a redundant fan pair and a 2-of-3 disk array. The engine reduces the success logic to one system-reliability figure and flags the power supply as the single point of failure.",
+    "standard": "IEC 61078",
+    "tags": [
+      "rbd",
+      "reliability",
+      "redundancy",
+      "series-parallel",
+      "k-of-n",
+      "spof",
+      "availability"
+    ],
+    "complexity": 2,
+    "featured": true,
+    "dsl": 'rbd "Redundant Server"\n  series {\n    block PSU "Power Supply" R=0.99\n    parallel {\n      block FAN1 "Fan A" R=0.95\n      block FAN2 "Fan B" R=0.95\n    }\n    kofn 2/3 {\n      block D1 "Disk 1" R=0.97\n      block D2 "Disk 2" R=0.97\n      block D3 "Disk 3" R=0.97\n    }\n  }',
+    "notes": "## What this shows\n\nThe three building blocks of reliability success logic in one diagram. The **single power supply** sits in series \u2014 everything depends on it. The **two fans** are in parallel, so the cooling subsystem survives either one failing. The **three disks** form a **2-of-3** array that tolerates one loss.\n\n**The number is computed, not drawn.** The engine reduces each group \u2014 fans to `1 \u2212 0.05\xB2 = 0.9975`, the disk array to `3\xB70.97\xB2\xB70.03 + 0.97\xB3 = 0.99735`, then multiplies the series chain \u2014 to a **system reliability of \u2248 0.9849**. It also derives each block's Birnbaum importance and flags the **power supply as the single point of failure** (red border): with no redundancy in series, its failure alone takes down the whole system, and it carries the highest importance \u2014 the first place to add redundancy."
+  },
+  {
+    "slug": "rbd-sif-emergency-shutdown",
+    "diagram": "rbd",
+    "title": "Safety instrumented function (SIF) \u2014 emergency shutdown",
+    "description": "A reliability block diagram of an IEC 61511 emergency-shutdown loop \u2014 2-of-3 voting pressure transmitters, a redundant logic solver, and 1-out-of-2 shutdown valves. The classic sensor \u2192 logic \u2192 final-element SIF architecture, with the engine computing the loop reliability.",
+    "standard": "IEC 61078 / IEC 61511 (SIF)",
+    "tags": [
+      "rbd",
+      "reliability",
+      "safety",
+      "sif",
+      "sil",
+      "iec-61511",
+      "k-of-n",
+      "2oo3",
+      "1oo2",
+      "redundancy"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'rbd "Emergency Shutdown SIF (SIL 2)"\n  series {\n    kofn 2/3 {\n      block PT1 "Pressure Tx 1" R=0.98\n      block PT2 "Pressure Tx 2" R=0.98\n      block PT3 "Pressure Tx 3" R=0.98\n    }\n    parallel {\n      block LS1 "Logic solver A" R=0.999\n      block LS2 "Logic solver B" R=0.999\n    }\n    parallel {\n      block SDV1 "Shutdown valve A" R=0.96\n      block SDV2 "Shutdown valve B" R=0.96\n    }\n  }',
+    "notes": "## What this shows\n\nThe canonical safety-instrumented-function architecture from IEC 61511, laid out as a **series** of three subsystems: **sensing**, **logic**, and **final elements**. Sensing uses **2-out-of-3** voting transmitters (tolerates one failure *and* rejects one spurious trip); the **logic solver** is a redundant pair; the **final elements** are two shutdown valves in a **1-out-of-2** (parallel) arrangement so either can close the line.\n\n**The reliability is computed across the loop.** The engine evaluates the 2oo3 sensor group exactly, the two parallel pairs as `1 \u2212 (1\u2212R)\xB2`, and the series chain \u2014 giving a loop reliability of **\u2248 0.9972**. Because every subsystem is redundant, there's **no single point of failure**, and the importance ranking points at the valves (the lowest-reliability stage) as the place a SIL upgrade buys the most. The success-space companion to the fault tree a safety case also needs."
+  },
   {
     "slug": "sequence-combined-fragments-gallery",
     "diagram": "sequence",
@@ -4386,6 +4524,10 @@ var SYNTAX = {
   "playbook": {
     "title": "Sports playbook",
     "content": '## 1. Your first play\n\nEvery diagram starts with a header naming the **sport**, then a **formation** (which places the players), then **assignments**:\n\n```\nplaybook "Give & Go" sport basketball\nset 5-out\npass 1 2\ncut 1 rim\npass 2 1\n```\n\n`pass 1 2` draws a pass from player 1 to player 2; `cut 1 rim` sends player 1 to the rim. Basketball draws passes **dashed** and cuts **solid** \u2014 the convention on every coaching whiteboard.\n\n---\n\n## 2. The three sports\n\nPick the sport in the header (`sport football|basketball|soccer`). Each uses its real unit and the conventional coaching viewpoint:\n\n| Sport | Unit | View | Surface |\n|---|---|---|---|\n| `football` | yards | offense at the bottom attacking **up**; downfield = up | green field with yard lines, hashes, end zone |\n| `basketball` | feet | NBA **half-court**; baseline + hoop at the top | light maple hardwood |\n| `soccer` | metres | full **105 \xD7 68 m** pitch (attack toward the right); or `view half` | green pitch with IFAB markings |\n\n---\n\n## 3. Players & formations\n\nThe fastest way to place players is a **formation** (football/soccer) or **set** (basketball):\n\n- **Football** \u2014 `formation i-form | shotgun | singleback | pistol | spread | trips | empty | goal-line | wishbone` with optional strength `left`/`right`. Receivers are `X Z H Y` (Y = tight end), backs `QB RB FB`, line `LT LG C RG RT`.\n- **Basketball** \u2014 `set horns | 1-4-high | 1-4-low | box | spread-pnr | 4-out | 5-out`. Players are numbered `1`\u2013`5`.\n- **Soccer** \u2014 `formation 4-3-3 | 4-4-2 | 4-2-3-1 | 4-5-1 | 4-4-1-1 | 3-5-2 | 3-4-3`. Players are numbered `1` (GK) \u2026 `11`.\n\nFor set-pieces or free-form diagrams, place players individually and crop to a half:\n\n```\nplaybook "Overlap & Cross" sport soccer\nview half\nplayer 7 o at 75,12 label 7\nplayer 2 o at 60,15 label 2\nplayer 9 o at 88,30 label 9\nplayer 11 o at 85,52 label 11\nplayer 10 o at 80,38 label 10\ndribble 7 to 82,20\nrun 2 to 90,8\npass 7 to 90,8\npass 2 to 102,34\nrun 9 to 101,31\nrun 11 to 101,40\n```\n\n---\n\n## 4. Movement verbs & line styles\n\nThe same line style means different things in different sports \u2014 Schematex draws each sport\'s own convention, and the legend always matches:\n\n| Verb | Football | Basketball | Soccer |\n|---|---|---|---|\n| `pass` | dashed (throw) | **dashed** | **solid** |\n| `run` / `cut` | solid | **solid** (cut) | **dashed** (run) |\n| `dribble` | \u2014 | wavy | wavy |\n| `screen` / `block` | T-bar \u22A5 | T-bar \u22A5 (screen) | T-bar \u22A5 |\n| `shot` | \u2014 | solid | double line |\n\n**Note the inversion:** basketball draws a pass *dashed* and a cut *solid*; soccer draws a pass *solid* and a run *dashed*. That is how the two coaching communities actually diagram \u2014 Schematex honours each.\n\nMove targets can be a **player id**, a **landmark** name, or explicit **coordinates** (`to x,y`).\n\n---\n\n## 5. Football \u2014 routes, runs, defense\n\nPass routes use the **route tree**: `go fly streak slant flat hitch out in dig curl comeback corner post wheel cross drag seam`. Run concepts: `dive iso power counter sweep toss draw trap`. Blocking uses `block`, `pull`, and `handoff`. Set `goal N` to draw the end zone and goalposts:\n\n```\nplaybook "Red Zone \u2014 Play-Action Fade" sport football\nfield down 1 distance 5 los 5 goal 5 hash nfl\nformation i-form right\ndefense cover-1\nhandoff QB RB\nroute Z corner 4\nroute X slant\nroute Y out 3\nrun RB dive right\n```\n\n`defense cover-0/1/2/3/4/6` draws the coverage shell; `defense 4-3 | 3-4 | nickel | dime` sets the front. `hash nfl|college|none` controls the hash marks.\n\n---\n\n## 6. Basketball \u2014 sets, landmarks, screens\n\nCuts and passes target **named landmarks** \u2014 `rim elbow wing corner short-corner block slot top high-post dunker` (prefix `l`/`r` for left/right). `screen A B` draws a ball-screen (T-bar) for player B; `dribble` is a wavy line:\n\n```\nplaybook "Spread Pick & Roll" sport basketball\nset spread-pnr\nscreen 5 1\ndribble 1 to 11,17\ncut 5 rim\npass 1 2\n```\n\n`defense man` matches each defender to a man; `defense zone-2-3 | zone-3-2 | zone-1-3-1` draws a zone front.\n\n---\n\n## 7. Soccer \u2014 shapes, runs, build-up\n\nA formation alone draws the team shape. Add `pass` (solid), `run` (dashed), and `dribble` (wavy) to show a phase of play:\n\n```\nplaybook "Build-Up From the Back" sport soccer\nformation 4-3-3\npass 1 4\npass 4 2\nrun 2 to 40,10\npass 4 6\nrun 6 to 62,24\n```\n\nLandmarks include `box top-box d penalty-spot near-post far-post six-yard center`. `defense low-block | mid-block | high-press` overlays the opponent\'s shape. Soccer renders daylight-only \u2014 `theme: dark` falls back to the default pitch.\n\n---\n\n## 8. Validation\n\nThe engine rejects the mistakes models actually make and lists the valid options:\n\n- unknown `sport`, `formation` / `set`, `defense`, or named route;\n- a move referencing an undeclared player id;\n- a malformed coordinate or a missing `to` target.\n\nSofter issues (e.g. a zero-length move) render with a warning rather than failing.\n\n---\n\n## 9. Grammar (EBNF)\n\n```text\nplaybook   = "playbook" string "sport" sport NL { stmt NL } ;\nsport      = "football" | "basketball" | "soccer" ;\nstmt       = field | formation | defense | player | move | zone | "view" view ;\nfield      = "field" { "down" num | "distance" num | "los" num\n                     | "goal" num | "hash" hash | "view" view } ;\nformation  = ( "formation" | "set" ) name [ "left" | "right" ] ;\ndefense    = "defense" scheme ;\nplayer     = "player" id pos "at" coord "label" text ;\nmove       = route | run | pass | cut | dribble | screen\n           | shot | motion | handoff | pull | block ;\nroute      = "route" id namedRoute [ num ] [ "left" | "right" ] ;\nrun        = "run" id ( concept [ "left" | "right" ] | "to" coord ) ;\npass       = "pass" id ( id | landmark | "to" coord ) ;\ncut        = "cut" id ( landmark | "to" coord ) ;\ndribble    = "dribble" id "to" coord ;\nscreen     = "screen" id id ;\nshot       = "shot" id [ "to" coord ] ;\nzone       = "zone" coord coord string ;\ncoord      = num "," num ;\nview       = "full" | "half" ;\nhash       = "nfl" | "college" | "none" ;\n```\n\n---\n\n## Related examples\n\nFive canonical plays per sport ship as examples \u2014 Four Verticals, Mesh, Smash, Power O, and a Red-Zone fade for football; Pick & Roll, Horns, Give & Go, Floppy, and a Backdoor cut for basketball; 4-3-3 shape, Build-Up, Overlap, High Press, and Counter-Attack for soccer.'
+  },
+  "rbd": {
+    "title": "Reliability Block Diagram",
+    "content": '## 1. Your first diagram\n\nEvery document starts with the `rbd` keyword (alias `reliability`), an optional title, then nested success-logic groups around `block` leaves:\n\n```\nrbd "Two redundant pumps"\n  parallel {\n    block A "Pump A" R=0.9\n    block B "Pump B" R=0.9\n  }\n```\n\nThe engine draws the two pumps on parallel rails between a split node and a join node, computes the system reliability `1 \u2212 (1\u22120.9)(1\u22120.9) = 0.99`, and prints it as the headline. A bare top-level list of blocks (no outer group) is treated as a **series** chain.\n\n## 2. Blocks\n\nA `block` is one component on a success path:\n\n```\nblock ID "Label" R=0.99\n```\n\n- `ID` \u2014 a short identifier (shown when no label is given).\n- `"Label"` \u2014 an optional display name (CJK quotes welcome).\n- Reliability is given as **`R=0.99`** (reliability/availability), **`p=0.01`** (probability of *failure*, \u2192 R = 1\u2212p), or a percentage **`R=99%`**. A block with no reliability leaves the system figure symbolic (`n/a`).\n\n## 3. Success-logic groups\n\nGroups nest freely, so you can model redundant chains, voting banks, and standby pairs:\n\n| Group | Succeeds when | Reliability |\n|-------|---------------|-------------|\n| `series { \u2026 }` | **every** child works | \u220F R\u1D62 |\n| `parallel { \u2026 }` | **any** child works | 1 \u2212 \u220F(1 \u2212 R\u1D62) |\n| `kofn k/n { \u2026 }` | **\u2265 k of n** children work | exact state enumeration |\n\n```\nseries {\n  block CTRL "Controller" R=0.995\n  parallel {\n    series { block P1 "Path 1 sensor" R=0.97\n             block A1 "Path 1 actuator" R=0.98 }\n    series { block P2 "Path 2 sensor" R=0.97\n             block A2 "Path 2 actuator" R=0.98 }\n  }\n}\n```\n\n## 4. Computed reliability, importance & SPOF\n\nAfter parsing, the engine computes:\n\n- **System reliability** \u2014 the headline figure, by recursive series/parallel/k-of-n reduction.\n- **Birnbaum importance** `I\u1D2E(i) = R_sys(R\u1D62=1) \u2212 R_sys(R\u1D62=0)` for every block; the highest-importance block (the improvement target) is accented.\n- **Single points of failure** \u2014 any block where `R_sys(R\u1D62=0) = 0` (its failure alone fails the system) is drawn with a red border. A non-redundant block in series is always a SPOF.\n\n## 5. Validation\n\nThe parser reports non-fatal warnings rather than failing:\n\n- a `kofn k/n` threshold with `k > n` is clamped to `n` (and `k < 1` to `1`);\n- a reliability outside `0..1` is clamped;\n- a duplicate block id is flagged.\n\n## 6. Theming\n\n`theme: default` uses the shared risk-reliability palette (neutral blocks, blue reliability numerals, red single-point-of-failure borders). `theme: monochrome` renders a black-and-white print version (SPOF by border weight); `theme: dark` is the Catppuccin dark variant.'
   }
 };
 
@@ -5645,6 +5787,44 @@ var PROFILES = {
       "'has no effect/cause' -> every failure mode needs at least one effect and one cause."
     ]
   },
+  rbd: {
+    type: "rbd",
+    header: 'rbd "Title"',
+    mode: "brace-nested success logic: series/parallel/kofn groups wrapping `block` leaves",
+    keywords: 'header: rbd | reliability \xB7 groups: series { \u2026 } | parallel { \u2026 } | kofn k/n { \u2026 } (nestable) \xB7 leaf: block ID "Label" R=0.99 (also p=0.01 failure prob, or R=99%) \xB7 engine computes system reliability + Birnbaum importance + SPOF',
+    forms: [
+      'rbd "Redundant Server"',
+      "series {",
+      '  block PSU "Power Supply" R=0.99',
+      "  parallel {",
+      '    block FAN1 "Fan A" R=0.95',
+      '    block FAN2 "Fan B" R=0.95',
+      "  }",
+      "  kofn 2/3 {",
+      '    block D1 "Disk 1" R=0.97',
+      '    block D2 "Disk 2" R=0.97',
+      '    block D3 "Disk 3" R=0.97',
+      "  }",
+      "}"
+    ],
+    prefer: [
+      "Single-word keyword is `rbd` (alias `reliability`). Nest `series`/`parallel`/`kofn k/n` groups with braces around `block` leaves.",
+      "Give every block a reliability: `R=0.99` (or failure prob `p=0.01`, or `R=99%`); the engine then computes system reliability.",
+      "Use `parallel { \u2026 }` for full redundancy and `kofn 2/3 { \u2026 }` for k-out-of-n voting redundancy.",
+      "Groups nest freely \u2014 e.g. a `parallel` of two `series` strings models redundant chains.",
+      "A bare top-level list of blocks (no outer group) is treated as a series chain."
+    ],
+    avoid: [
+      "Don't omit the `block` keyword's reliability if you want a number \u2014 a block with no R leaves the system reliability symbolic.",
+      "Don't forget to close every `{` with a `}` \u2014 groups are brace-delimited, not indentation-driven.",
+      "Don't write `kofn` without a `k/n` threshold (e.g. `kofn 2/3 { \u2026 }`)."
+    ],
+    repair: [
+      "'needs a k/n threshold' -> write `kofn 2/3 { \u2026 }` with the threshold before the brace.",
+      "'Unclosed group' -> add the missing `}`.",
+      "If system reliability shows 'n/a', a block is missing its `R=`/`p=`."
+    ]
+  },
   causalloop: {
     type: "causalloop",
     header: 'causalloop "Title"',
@@ -6036,7 +6216,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 = chunkGTCAJPQR_cjs.parseResult(dsl, config);
+  const result = chunkQ7CWX6HA_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6062,7 +6242,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunkGTCAJPQR_cjs.renderResult(dsl, config);
+  const result = chunkQ7CWX6HA_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6124,5 +6304,5 @@ exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.resolveDiagramType = resolveDiagramType;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-TX3YWZZX.cjs.map
-//# sourceMappingURL=chunk-TX3YWZZX.cjs.map
+//# sourceMappingURL=chunk-7EWP4OD7.cjs.map
+//# sourceMappingURL=chunk-7EWP4OD7.cjs.map