schematex 0.9.4 → 0.9.6

package/dist/{chunk-TX3YWZZX.cjs → chunk-HX64QWB6.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkGTCAJPQR_cjs = require('./chunk-GTCAJPQR.cjs');
+var chunkKH5GRKUM_cjs = require('./chunk-KH5GRKUM.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -258,12 +258,34 @@ var DIAGRAM_REGISTRY = [
   // ── Project management / scheduling ──────────────────────────
   {
     type: "pert",
-    name: "PERT / CPM network",
-    tagline: "Activity-on-node project schedule that computes ES/EF/LS/LF, slack, and the critical path.",
-    useWhen: "Use whenever the user mentions 'PERT', 'CPM', 'critical path', 'project network', 'precedence diagram', or wants a project schedule from tasks + durations + dependencies. Unlike a flowchart, this engine *computes* the schedule: write `task <id> \"label\" duration: <n> after: <preds>` and it runs the forward/backward pass and returns Early/Late Start & Finish, total slack, project duration, and highlights the critical path in red. Supports PDM dependency types (FS/SS/FF/SF) with lag/lead (`after: A SS+2d`), three-point estimation (`duration: 4/6/10` \u2192 te + variance), milestones (`milestone`), swimlanes (`lane: \"Team\"`), a `layout: timescaled` mode (x \u221D ES, width \u221D duration) for a network-Gantt hybrid, and a legacy `layout: aoa` mode (activity-on-arrow: numbered event circles + arrow activities + dummy activities, FS-only). Distinct from `flowchart` (no scheduling), `timeline`/Gantt (no critical-path computation), and `bpmn` (organisational process, not a one-off schedule).",
+    name: "PERT / CPM network & Gantt chart",
+    tagline: "Activity-on-node project schedule that computes ES/EF/LS/LF, slack, and the critical path \u2014 rendered as a network, a timescale, or a calendar Gantt.",
+    useWhen: "Use whenever the user mentions 'PERT', 'CPM', 'critical path', 'Gantt chart', 'project schedule', 'project network', 'precedence diagram', or wants a project schedule from tasks + durations + dependencies. Unlike a flowchart, this engine *computes* the schedule: write `task <id> \"label\" duration: <n> after: <preds>` and it runs the forward/backward pass and returns Early/Late Start & Finish, total slack, project duration, and highlights the critical path in red. **For a Gantt chart use the `gantt` header (or `layout: gantt`)** \u2014 bars are placed from the computed ES/EF (not typed-in dates, the way Mermaid requires), one task per row, grouped into sections by `lane:`, with a calendar date axis from `start: YYYY-MM-DD` (`calendar: continuous`|`5day` to exclude weekends), `progress: 60%` overlays, `milestone` diamonds, dependency connectors, an optional `today:` marker, and the critical path drawn in red. Supports PDM dependency types (FS/SS/FF/SF) with lag/lead (`after: A SS+2d`), three-point estimation (`duration: 4/6/10` \u2192 te + variance), a `layout: timescaled` mode, and a legacy `layout: aoa` mode (activity-on-arrow). Distinct from `flowchart` (no scheduling), `timeline` (no critical-path computation), and `bpmn` (organisational process, not a one-off schedule).",
     cluster: "project-management",
-    standard: "PMI PMBOK 7 + Moder 1983 (AON/PDM); see 32-PERT-STANDARD.md",
-    syntaxKey: "pert"
+    standard: "PMI PMBOK 7 + Moder 1983 (AON/PDM); Gantt 1910; see 32-PERT-STANDARD.md",
+    syntaxKey: "pert",
+    aliases: [
+      "PERT chart",
+      "CPM",
+      "critical path method",
+      "Gantt chart",
+      "gantt",
+      "project schedule",
+      "precedence diagram",
+      "\u7518\u7279\u56FE"
+    ],
+    keywords: [
+      "critical path",
+      "project management",
+      "project schedule",
+      "task dependencies",
+      "gantt chart maker",
+      "project timeline",
+      "forward backward pass",
+      "slack float",
+      "milestone",
+      "PMBOK"
+    ]
   },
   // ── Structural UML ───────────────────────────────────────────
   {
@@ -389,6 +411,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 +742,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);
@@ -2024,6 +2076,45 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'fmea "Injection moulding PFMEA"\n  type: process\n  rank: rpn\n  flag: rpn > 100\n  item "Mould fill step" fn "Fill cavity with melt"\n    mode "Short shot"\n      effect "Incomplete part scrapped" sev: 7\n      cause "Injection pressure too low" occ: 5\n        controls prevention: "Pressure setpoint lock", detection: "Vision check" det: 4\n      cause "Blocked gate" occ: 3\n        controls detection: "Cycle-time monitor" det: 6\n  item "Cooling step" fn "Solidify part to spec"\n    mode "Warpage"\n      effect "Out-of-tolerance dimension" sev: 6\n      cause "Uneven cooling channel flow" occ: 6\n        controls detection: "CMM sampling" det: 7',
     "notes": "## What this shows\n\nA process FMEA (PFMEA) following the steps of an injection-moulding line \u2014 the fill step and the cooling step \u2014 rather than the parts of a product. Each process step gets its failure modes (short shot, warpage), the effect each has on the part, the process causes behind it, and the in-line controls that prevent or detect it.\n\nThis worksheet is ranked the legacy way with `rank: rpn`, so the engine sorts purely on RPN = S \xD7 O \xD7 D and the `flag: rpn > 100` directive lights up every row above 100 \u2014 here the uneven-cooling warpage row at S6\xB7O6\xB7D7 (RPN 252) and the short-shot pressure row at S7\xB7O5\xB7D4 (RPN 140). Each rendered row carries `data-rpn` and `data-ap`, so even on a legacy RPN worksheet the AIAG-VDA Action Priority is still computed and inspectable underneath."
   },
+  {
+    "slug": "gantt-construction-schedule",
+    "diagram": "pert",
+    "title": "Construction schedule (Gantt, computed critical path)",
+    "description": "A residential construction Gantt on a continuous calendar \u2014 excavation through handover. The engine computes the critical path (excavation \u2192 foundation \u2192 framing \u2192 electrical \u2192 drywall \u2192 finishes \u2192 handover) and shows the float on the parallel roofing and plumbing trades.",
+    "standard": "PMI PMBOK 7 (critical path) + Gantt 1910",
+    "tags": [
+      "gantt",
+      "pert",
+      "cpm",
+      "critical-path",
+      "construction",
+      "project-schedule"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'gantt "Residential Build"\n  start: 2026-09-01\n  calendar: continuous\n  task EXC "Excavation" duration: 6\n  task FND "Foundation" duration: 8 after: EXC\n  task FRM "Framing" duration: 12 after: FND\n  task ROOF "Roofing" duration: 6 after: FRM\n  task ELEC "Electrical" duration: 8 after: FRM\n  task PLMB "Plumbing" duration: 7 after: FRM\n  task DRY "Drywall" duration: 6 after: ELEC, PLMB, ROOF\n  task FIN "Finishes" duration: 10 after: DRY\n  task HAND "Handover" milestone after: FIN',
+    "notes": "## What this shows\n\nOnce framing finishes, three trades \u2014 **roofing, electrical, plumbing** \u2014 run in parallel, but drywall can't start until all three are done. The engine works out that **electrical** is the longest of the three, so it lands on the critical path while roofing and plumbing carry float (drawn in blue with their slack). The critical chain `Excavation \u2192 Foundation \u2192 Framing \u2192 Electrical \u2192 Drywall \u2192 Finishes \u2192 Handover` is in red, and `Handover` is a milestone diamond. On a `continuous` calendar the bars span weekends; switch to `calendar: 5day` for a working-day timeline."
+  },
+  {
+    "slug": "gantt-website-relaunch",
+    "diagram": "pert",
+    "title": "Gantt chart with computed critical path (website relaunch)",
+    "description": "A calendar Gantt for a website relaunch \u2014 sections, a weekday-only date axis, progress overlays, a milestone, and a today marker. The bars are placed from the engine's computed schedule, so the critical path is highlighted in red and off-path tasks show their slack \u2014 something a hand-placed (Mermaid) Gantt can't do.",
+    "standard": "PMI PMBOK 7 (critical path) + Gantt 1910",
+    "tags": [
+      "gantt",
+      "pert",
+      "cpm",
+      "critical-path",
+      "project-schedule",
+      "milestone",
+      "calendar"
+    ],
+    "complexity": 3,
+    "featured": true,
+    "dsl": 'gantt "Website Relaunch"\n  start: 2026-07-01\n  calendar: 5day\n  task A "Discovery" duration: 5 lane: "Plan"\n  task B "Wireframes" duration: 8 after: A lane: "Design"\n  task C "Visual design" duration: 6 after: B lane: "Design" progress: 40%\n  task D "Frontend build" duration: 12 after: C lane: "Build"\n  task E "Backend API" duration: 10 after: A lane: "Build"\n  task F "Integration & QA" duration: 5 after: D, E lane: "Build"\n  task LAUNCH "Go live" milestone after: F lane: "Build"\n  today: 2026-07-20',
+    "notes": '## What this shows\n\nA real Gantt chart where **you type dependencies, not dates**. Each task declares a duration and what it comes `after:`; the engine runs the forward/backward pass and *places the bars* from the computed Early Start / Early Finish.\n\n**The critical path is computed and drawn in red** \u2014 `A \u2192 B \u2192 C \u2192 D \u2192 F \u2192 Go live`. "Backend API" runs in parallel off the critical path, so it\'s drawn in the resting blue with its **slack** annotated: you can start it 16 working days late without slipping the launch. The `5day` calendar excludes weekends from the timeline, `lane:` bands the rows into Plan / Design / Build sections, the 40 % progress overlay marks how far Visual design has got, and the dashed **today** line shows where the project stands. This is the differentiator over a typed Gantt: change one duration and the whole schedule \u2014 and the critical path \u2014 recomputes.'
+  },
   {
     "slug": "genogram-brca-cancer",
     "diagram": "genogram",
@@ -3453,6 +3544,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",
@@ -4321,7 +4520,7 @@ var SYNTAX = {
   },
   "pert": {
     "title": "PERT / CPM Network",
-    "content": '## 1. Your first diagram\n\nEvery document starts with the `pert` keyword, an optional header, then one `task` line per activity:\n\n```\npert\nunit: days\n\ntask A "Market research" duration: 5\ntask B "Design mockups"  duration: 8 after: A\ntask C "Backend API"     duration: 15 after: A\ntask D "Frontend build"  duration: 10 after: B, C\n```\n\nEach task carries an `<id>`, a quoted `<label>`, a `duration:`, and an optional `after:` list of predecessors. The engine adds an invisible Start and Finish, runs the schedule, and draws the six-field activity box for every task. You never type ES/EF/LS/LF \u2014 they are computed.\n\nThe header accepts:\n\n- `title: "\u2026"` \u2014 a heading drawn above the diagram.\n- `unit: days | weeks | hours | abstract` \u2014 the time unit (default `days`; purely a label, the engine is calendar-agnostic).\n- `direction: LR | TB` \u2014 left-to-right (default) or top-to-bottom.\n- `layout: network | timescaled` \u2014 the layered network (default) or a time-proportional view (\xA76).\n- `critical-tolerance: <n>` \u2014 slack \u2264 this counts as critical (default `0`; set `0.001` for three-point projects).\n- `show-sentinels: true` \u2014 draw the synthetic Start / Finish nodes (hidden by default).\n\n---\n\n## 2. The six-field activity box\n\nEvery task renders as the canonical 3\xD72 PERT/CPM rectangle:\n\n```\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502  ES      \u2502  Duration  \u2502   EF     \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502         Task Name (ID)           \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502  LS      \u2502  Slack     \u2502   LF     \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n- **ES / EF** \u2014 Early Start / Early Finish, from the forward pass.\n- **LS / LF** \u2014 Late Start / Late Finish, from the backward pass.\n- **Slack** (total float) = LS \u2212 ES = LF \u2212 EF. Zero slack means the activity is on the critical path.\n\nCritical activities get a **red border** and a bold `0` slack; the project\'s critical chain reads as an unbroken red line. Every field is also mirrored onto `data-*` attributes (`data-es`, `data-slack`, `data-critical`, \u2026) so you can query the SVG without re-running the math.\n\n**On the two-colour palette.** A PERT chart is deliberately drawn in just two colours. Red for the critical path is a genuine industry convention \u2014 MS Project, Oracle Primavera P6, and PMBOK figures all use it, because "critical vs. not" is the one distinction the diagram exists to surface. Everything else stays a neutral house-blue. Adding more colours would imply categories that PERT\'s semantics don\'t have; if you need to group by team or phase, use [swimlanes](#7-swimlanes-tags-classes-and-comments) (`lane:`) instead of colour.\n\n---\n\n## 3. Dependencies (FS / SS / FF / SF + lag/lead)\n\n`after:` takes a comma-separated list of predecessor references. The default relationship is **Finish-to-Start (FS)** \u2014 a task starts once its predecessor finishes:\n\n```\ntask D "Frontend build" duration: 10 after: B, C\n```\n\nModern scheduling needs the other three Precedence-Diagramming relationships and **lag** (delay) or **lead** (negative lag):\n\n```\ntask B "Stakeholder interviews" duration: 6 after: A SS+1   # start 1d after A starts\ntask I "Documentation"          duration: 4 after: D+3      # FS with a 3-day lag\ntask J "Translation"            duration: 3 after: I SS-1   # start 1d before I starts (lead)\ntask K "Sign-off"               duration: 1 after: I FF     # finishes when I finishes\ntask L "Press release"          duration: 2 after: G SF+1   # start-to-finish (rare)\n```\n\n| Form | Meaning |\n|------|---------|\n| `after: A` | Finish-to-Start, no lag (the common case) |\n| `after: A+2` or `after: A+2d` | FS with a 2-unit lag |\n| `after: A SS` / `A FF` / `A SF` | Start-to-Start / Finish-to-Finish / Start-to-Finish |\n| `after: A SS+2d` / `A FF-1d` | any type with lag (`+`) or lead (`-`) |\n\nA lag unit suffix (`d` / `w` / `h`) must match the diagram\'s `unit:` or be omitted; mixed units are rejected. FS with zero lag is unlabelled; SS/FF/SF always show their type on the edge.\n\n---\n\n## 4. Three-point (PERT) estimation\n\nWrite a duration as `O/M/P` (optimistic / most-likely / pessimistic) and the engine computes the beta-distribution expected duration **te = (O + 4M + P) / 6** and the variance **\u03C3\xB2 = ((P \u2212 O)/6)\xB2**:\n\n```\npert\ncritical-tolerance: 0.01\ntask A "Spec"   duration: 2/3/5    # te = 3.17, \u03C3\xB2 = 0.25\ntask B "Build"  duration: 5/8/14   after: A   # te = 8.50, \u03C3\xB2 = 2.25\ntask C "Test"   duration: 3/4/6    after: B\ntask D "Deploy" duration: 1/2/3    after: C\n```\n\nThe Duration field shows `te`; a small `\u03C3=\u2026` annotation appears under the name; and the project-level standard deviation (\u221A of the summed critical-path variances) is reported in the footer. Use `critical-tolerance: 0.01` so floating-point `te` values don\'t displace the visible critical path.\n\n---\n\n## 5. Milestones\n\nA milestone is a zero-duration checkpoint, drawn as a diamond. Use the `milestone` flag or `duration: 0`:\n\n```\ntask P "Cutover weekend" milestone after: O\ntask Q "Go-live"         duration: 0 after: P\n```\n\n---\n\n## 6. Time-scaled layout\n\n`layout: timescaled` switches from the layered network to a network-Gantt hybrid: each activity\'s **x-position is proportional to its ES** and its **width is proportional to its duration**, with a unit time axis along the bottom. Activities are packed into lanes so nothing overlaps.\n\n```\npert\nlayout: timescaled\nunit: days\n\ntask A "Inventory"     duration: 5\ntask B "Interviews"    duration: 6  after: A SS+1\ntask C "Design"        duration: 10 after: A, B\ntask D "Build"         duration: 15 after: C\ntask E "Pilot"         duration: 7  after: D\n```\n\nThis is a bridge to a Gantt view, not a replacement: there\'s no calendar, working-time mask, or resource swimlane.\n\n### Activity-on-arrow (`layout: aoa`)\n\n`layout: aoa` renders the older **activity-on-arrow** (ADM) notation you\'ll find in textbooks and on Investopedia: numbered **event** circles, **activities as labelled arrows**, and dotted **dummy activities** auto-inserted wherever an activity has two or more predecessors. You write the same activity-on-node DSL \u2014 Schematex builds the event graph and numbers the events for you.\n\n```\npert\nlayout: aoa\nunit: days\n\ntask A "create schedule" duration: 10\ntask B "buy hardware"    duration: 5\ntask C "programming"     duration: 20 after: A\ntask D "installation"    duration: 5  after: B\ntask E "conversion"      duration: 15 after: D\ntask F "test code"       duration: 20 after: C, E\ntask G "write manual"    duration: 15 after: E\n```\n\nAOA is a **legacy** notation (PMBOK 7 dropped it; AON is the modern standard) and it can only express **finish-to-start** logic \u2014 SS/FF/SF and lag/lead are flattened to FS with a warning. Use it for teaching, exam prep, or matching an existing textbook figure; use the default `network` (AON) layout for real scheduling.\n\n---\n\n## 7. Swimlanes, tags, classes, and comments\n\nAdd `lane: "\u2026"` to any task and the network re-groups into horizontal swimlanes \u2014 by responsible team, phase, or owner \u2014 while still computing the schedule exactly as before:\n\n```\ntask T1 "Support Account Deletion" duration: 3  lane: "Customer Account"\ntask T2 "Design a New Theme"        duration: 8  lane: "Shopping Site"\ntask T3 "Apply New Theme"           duration: 15 after: T2 lane: "Shopping Site"\n```\n\nLanes appear in first-declared order, each as a banded row with a label gutter on the left. Swimlanes are a presentation of the same AON network, not a different layout mode \u2014 they activate automatically when any task declares a lane.\n\n```\ntask X "External vendor work" duration: 10 after: A tags: vendor, external class: secondary\n# this is a comment\n```\n\n`tags:` emit `data-tag="\u2026"` on the node group and `class:` adds a CSS class for downstream theming. `#` and `//` start a comment to end of line.\n\n---\n\n## 8. Grammar (EBNF)\n\n```text\ndocument    = "pert" NEWLINE header* task+\nheader      = "title:" quoted\n            | "unit:" ("days" | "weeks" | "hours" | "abstract")\n            | "direction:" ("LR" | "TB")\n            | "layout:" ("network" | "timescaled" | "aoa")\n            | "critical-tolerance:" number\n            | "show-sentinels:" boolean\n\ntask        = "task" IDENT quoted "duration:" duration ("after:" reflist)? "milestone"? attrs?\n            | "task" IDENT quoted "milestone" ("after:" reflist)? attrs?\nduration    = number | number "/" number "/" number          ; deterministic or O/M/P\nreflist     = ref ("," ref)*\nref         = IDENT (WS deptype)? laglead?\n            | IDENT "+" number unit?                          ; attached FS lag sugar\ndeptype     = "FS" | "SS" | "FF" | "SF"\nlaglead     = ("+" | "-") number unit?\nunit        = "d" | "w" | "h"\nattrs       = ("tags:" idlist)? ("class:" IDENT)? ("lane:" quoted)?\n```\n\n---'
+    "content": '## 1. Your first diagram\n\nEvery document starts with the `pert` keyword, an optional header, then one `task` line per activity:\n\n```\npert\nunit: days\n\ntask A "Market research" duration: 5\ntask B "Design mockups"  duration: 8 after: A\ntask C "Backend API"     duration: 15 after: A\ntask D "Frontend build"  duration: 10 after: B, C\n```\n\nEach task carries an `<id>`, a quoted `<label>`, a `duration:`, and an optional `after:` list of predecessors. The engine adds an invisible Start and Finish, runs the schedule, and draws the six-field activity box for every task. You never type ES/EF/LS/LF \u2014 they are computed.\n\nThe header accepts:\n\n- `title: "\u2026"` \u2014 a heading drawn above the diagram.\n- `unit: days | weeks | hours | abstract` \u2014 the time unit (default `days`; purely a label, the engine is calendar-agnostic).\n- `direction: LR | TB` \u2014 left-to-right (default) or top-to-bottom.\n- `layout: network | timescaled` \u2014 the layered network (default) or a time-proportional view (\xA76).\n- `critical-tolerance: <n>` \u2014 slack \u2264 this counts as critical (default `0`; set `0.001` for three-point projects).\n- `show-sentinels: true` \u2014 draw the synthetic Start / Finish nodes (hidden by default).\n\n---\n\n## 2. The six-field activity box\n\nEvery task renders as the canonical 3\xD72 PERT/CPM rectangle:\n\n```\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502  ES      \u2502  Duration  \u2502   EF     \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502         Task Name (ID)           \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502  LS      \u2502  Slack     \u2502   LF     \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n- **ES / EF** \u2014 Early Start / Early Finish, from the forward pass.\n- **LS / LF** \u2014 Late Start / Late Finish, from the backward pass.\n- **Slack** (total float) = LS \u2212 ES = LF \u2212 EF. Zero slack means the activity is on the critical path.\n\nCritical activities get a **red border** and a bold `0` slack; the project\'s critical chain reads as an unbroken red line. Every field is also mirrored onto `data-*` attributes (`data-es`, `data-slack`, `data-critical`, \u2026) so you can query the SVG without re-running the math.\n\n**On the two-colour palette.** A PERT chart is deliberately drawn in just two colours. Red for the critical path is a genuine industry convention \u2014 MS Project, Oracle Primavera P6, and PMBOK figures all use it, because "critical vs. not" is the one distinction the diagram exists to surface. Everything else stays a neutral house-blue. Adding more colours would imply categories that PERT\'s semantics don\'t have; if you need to group by team or phase, use [swimlanes](#7-swimlanes-tags-classes-and-comments) (`lane:`) instead of colour.\n\n---\n\n## 3. Dependencies (FS / SS / FF / SF + lag/lead)\n\n`after:` takes a comma-separated list of predecessor references. The default relationship is **Finish-to-Start (FS)** \u2014 a task starts once its predecessor finishes:\n\n```\ntask D "Frontend build" duration: 10 after: B, C\n```\n\nModern scheduling needs the other three Precedence-Diagramming relationships and **lag** (delay) or **lead** (negative lag):\n\n```\ntask B "Stakeholder interviews" duration: 6 after: A SS+1   # start 1d after A starts\ntask I "Documentation"          duration: 4 after: D+3      # FS with a 3-day lag\ntask J "Translation"            duration: 3 after: I SS-1   # start 1d before I starts (lead)\ntask K "Sign-off"               duration: 1 after: I FF     # finishes when I finishes\ntask L "Press release"          duration: 2 after: G SF+1   # start-to-finish (rare)\n```\n\n| Form | Meaning |\n|------|---------|\n| `after: A` | Finish-to-Start, no lag (the common case) |\n| `after: A+2` or `after: A+2d` | FS with a 2-unit lag |\n| `after: A SS` / `A FF` / `A SF` | Start-to-Start / Finish-to-Finish / Start-to-Finish |\n| `after: A SS+2d` / `A FF-1d` | any type with lag (`+`) or lead (`-`) |\n\nA lag unit suffix (`d` / `w` / `h`) must match the diagram\'s `unit:` or be omitted; mixed units are rejected. FS with zero lag is unlabelled; SS/FF/SF always show their type on the edge.\n\n---\n\n## 4. Three-point (PERT) estimation\n\nWrite a duration as `O/M/P` (optimistic / most-likely / pessimistic) and the engine computes the beta-distribution expected duration **te = (O + 4M + P) / 6** and the variance **\u03C3\xB2 = ((P \u2212 O)/6)\xB2**:\n\n```\npert\ncritical-tolerance: 0.01\ntask A "Spec"   duration: 2/3/5    # te = 3.17, \u03C3\xB2 = 0.25\ntask B "Build"  duration: 5/8/14   after: A   # te = 8.50, \u03C3\xB2 = 2.25\ntask C "Test"   duration: 3/4/6    after: B\ntask D "Deploy" duration: 1/2/3    after: C\n```\n\nThe Duration field shows `te`; a small `\u03C3=\u2026` annotation appears under the name; and the project-level standard deviation (\u221A of the summed critical-path variances) is reported in the footer. Use `critical-tolerance: 0.01` so floating-point `te` values don\'t displace the visible critical path.\n\n---\n\n## 5. Milestones\n\nA milestone is a zero-duration checkpoint, drawn as a diamond. Use the `milestone` flag or `duration: 0`:\n\n```\ntask P "Cutover weekend" milestone after: O\ntask Q "Go-live"         duration: 0 after: P\n```\n\n---\n\n## 6. Time-scaled layout\n\n`layout: timescaled` switches from the layered network to a network-Gantt hybrid: each activity\'s **x-position is proportional to its ES** and its **width is proportional to its duration**, with a unit time axis along the bottom. Activities are packed into lanes so nothing overlaps.\n\n```\npert\nlayout: timescaled\nunit: days\n\ntask A "Inventory"     duration: 5\ntask B "Interviews"    duration: 6  after: A SS+1\ntask C "Design"        duration: 10 after: A, B\ntask D "Build"         duration: 15 after: C\ntask E "Pilot"         duration: 7  after: D\n```\n\nThis is the network-flavoured time view; for a calendar Gantt chart with one row per task, use `layout: gantt` (next).\n\n### Gantt chart (`gantt` / `layout: gantt`)\n\nStart a document with the **`gantt`** header (sugar for `pert` + `layout: gantt`) for a calendar Gantt. It is the *same scheduler* \u2014 so the bars are placed from the **computed** ES/EF, and the **critical path is drawn in red**, the thing a hand-placed Gantt (Mermaid) can\'t do: there you type the dates yourself, here you type dependencies and the engine schedules them.\n\n```\ngantt "Website Relaunch"\nstart: 2026-07-01\ncalendar: 5day\ntask A "Discovery"      duration: 5  lane: "Plan"\ntask B "Wireframes"     duration: 8  after: A   lane: "Design"\ntask C "Visual design"  duration: 6  after: B   lane: "Design"  progress: 40%\ntask D "Frontend build" duration: 12 after: C   lane: "Build"\ntask E "Backend API"    duration: 10 after: A   lane: "Build"\ntask F "Integration"    duration: 5  after: D, E lane: "Build"\ntask LAUNCH "Go live"   milestone    after: F   lane: "Build"\ntoday: 2026-07-20\n```\n\n- **`start: YYYY-MM-DD`** turns the axis into calendar dates (omit it for a numeric day-offset axis).\n- **`calendar: continuous`** (default) spans weekends; **`calendar: 5day`** excludes Sat/Sun from the timeline.\n- **`lane: "\u2026"`** groups tasks into labelled **sections**; **`progress: 60%`** draws a completion overlay; **`milestone`** is a diamond; **`today: YYYY-MM-DD`** drops a marker line.\n- One row per task, in declaration order. Off-critical-path bars are drawn in the resting blue with their **slack** annotated; critical bars are red.\n\n### Activity-on-arrow (`layout: aoa`)\n\n`layout: aoa` renders the older **activity-on-arrow** (ADM) notation you\'ll find in textbooks and on Investopedia: numbered **event** circles, **activities as labelled arrows**, and dotted **dummy activities** auto-inserted wherever an activity has two or more predecessors. You write the same activity-on-node DSL \u2014 Schematex builds the event graph and numbers the events for you.\n\n```\npert\nlayout: aoa\nunit: days\n\ntask A "create schedule" duration: 10\ntask B "buy hardware"    duration: 5\ntask C "programming"     duration: 20 after: A\ntask D "installation"    duration: 5  after: B\ntask E "conversion"      duration: 15 after: D\ntask F "test code"       duration: 20 after: C, E\ntask G "write manual"    duration: 15 after: E\n```\n\nAOA is a **legacy** notation (PMBOK 7 dropped it; AON is the modern standard) and it can only express **finish-to-start** logic \u2014 SS/FF/SF and lag/lead are flattened to FS with a warning. Use it for teaching, exam prep, or matching an existing textbook figure; use the default `network` (AON) layout for real scheduling.\n\n---\n\n## 7. Swimlanes, tags, classes, and comments\n\nAdd `lane: "\u2026"` to any task and the network re-groups into horizontal swimlanes \u2014 by responsible team, phase, or owner \u2014 while still computing the schedule exactly as before:\n\n```\ntask T1 "Support Account Deletion" duration: 3  lane: "Customer Account"\ntask T2 "Design a New Theme"        duration: 8  lane: "Shopping Site"\ntask T3 "Apply New Theme"           duration: 15 after: T2 lane: "Shopping Site"\n```\n\nLanes appear in first-declared order, each as a banded row with a label gutter on the left. Swimlanes are a presentation of the same AON network, not a different layout mode \u2014 they activate automatically when any task declares a lane.\n\n```\ntask X "External vendor work" duration: 10 after: A tags: vendor, external class: secondary\n# this is a comment\n```\n\n`tags:` emit `data-tag="\u2026"` on the node group and `class:` adds a CSS class for downstream theming. `#` and `//` start a comment to end of line.\n\n---\n\n## 8. Grammar (EBNF)\n\n```text\ndocument    = "pert" NEWLINE header* task+\nheader      = "title:" quoted\n            | "unit:" ("days" | "weeks" | "hours" | "abstract")\n            | "direction:" ("LR" | "TB")\n            | "layout:" ("network" | "timescaled" | "aoa")\n            | "critical-tolerance:" number\n            | "show-sentinels:" boolean\n\ntask        = "task" IDENT quoted "duration:" duration ("after:" reflist)? "milestone"? attrs?\n            | "task" IDENT quoted "milestone" ("after:" reflist)? attrs?\nduration    = number | number "/" number "/" number          ; deterministic or O/M/P\nreflist     = ref ("," ref)*\nref         = IDENT (WS deptype)? laglead?\n            | IDENT "+" number unit?                          ; attached FS lag sugar\ndeptype     = "FS" | "SS" | "FF" | "SF"\nlaglead     = ("+" | "-") number unit?\nunit        = "d" | "w" | "h"\nattrs       = ("tags:" idlist)? ("class:" IDENT)? ("lane:" quoted)?\n```\n\n---'
   },
   "petri": {
     "title": "Petri Net",
@@ -4386,6 +4585,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.'
   }
 };
 
@@ -5368,9 +5571,9 @@ var PROFILES = {
   },
   pert: {
     type: "pert",
-    header: "pert",
-    mode: "AON tasks with computed schedule (ES/EF/LS/LF/slack/critical path)",
-    keywords: 'pert \xB7 title: "\u2026" \xB7 unit: days|weeks|hours|abstract \xB7 direction: LR|TB \xB7 layout: network|timescaled|aoa \xB7 critical-tolerance: N \xB7 task ID "label" duration: N|O/M/P [after: ref,\u2026] [milestone] [lane: "Name"] \xB7 dependency refs: ID (FS) \xB7 ID FS|SS|FF|SF[+N|-N][d|w|h] \xB7 ID+N (FS lag sugar)',
+    header: "pert  (or `gantt` for a Gantt chart)",
+    mode: "AON tasks with computed schedule (ES/EF/LS/LF/slack/critical path); render as network, timescaled, or calendar Gantt",
+    keywords: 'pert | gantt \xB7 title: "\u2026" \xB7 unit: days|weeks|hours|abstract \xB7 direction: LR|TB \xB7 layout: network|timescaled|aoa|gantt \xB7 critical-tolerance: N \xB7 gantt-only: start: YYYY-MM-DD \xB7 calendar: continuous|5day \xB7 today: YYYY-MM-DD \xB7 task ID "label" duration: N|O/M/P [after: ref,\u2026] [milestone] [lane: "Section"] [progress: N%] \xB7 dependency refs: ID (FS) \xB7 ID FS|SS|FF|SF[+N|-N][d|w|h] \xB7 ID+N (FS lag sugar)',
     forms: [
       "pert",
       'title: "Q3 Product Launch"',
@@ -5381,12 +5584,21 @@ var PROFILES = {
       'task C "Backend API" duration: 15 after: A',
       'task D "Frontend build" duration: 10 after: B, C',
       'task E "QA / testing" duration: 5 after: D',
-      'task G "Launch event" duration: 2 after: E'
+      'task G "Launch event" duration: 2 after: E',
+      "",
+      "# \u2014 or a Gantt chart (same scheduler, calendar bars) \u2014",
+      'gantt "Website Relaunch"',
+      "start: 2026-07-01",
+      "calendar: 5day",
+      'task P "Discovery" duration: 5 lane: "Plan"',
+      'task Q "Build" duration: 12 after: P lane: "Build" progress: 30%',
+      'task R "Go live" milestone after: Q lane: "Build"'
     ],
     prefer: [
       'Each `task ID "label" duration: N` is one activity; wire dependencies with `after: A, B` (comma-separated, forward references allowed). The engine computes ES/EF/LS/LF and the critical path \u2014 never write those yourself.',
+      'For a Gantt chart, use the `gantt` header (or `layout: gantt`); add `start: YYYY-MM-DD` for a calendar date axis, `calendar: 5day` to exclude weekends, `lane: "Section"` to band rows, `progress: 60%` for completion, and `milestone` for diamonds. Bars are placed from the computed schedule \u2014 still never type ES/EF.',
       "Use three-point estimation `duration: O/M/P` (e.g. `2/3/5`) for uncertainty \u2014 the engine computes `te = (O+4M+P)/6` and variance; add `critical-tolerance: 0.01` when mixing estimate kinds.",
-      'Declare dependency types when needed: `after: A FS`, `after: A SS+2`, `after: B FF-1` (default FS, zero lag); group activities with `lane: "Team"`.'
+      "Declare dependency types when needed: `after: A FS`, `after: A SS+2`, `after: B FF-1` (default FS, zero lag)."
     ],
     avoid: [
       "Don't write `ES:`, `EF:`, `LS:`, `LF:`, or `slack:` yourself \u2014 they are computed outputs.",
@@ -5645,6 +5857,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 +6286,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 = chunkKH5GRKUM_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6062,7 +6312,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunkGTCAJPQR_cjs.renderResult(dsl, config);
+  const result = chunkKH5GRKUM_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6124,5 +6374,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-HX64QWB6.cjs.map
+//# sourceMappingURL=chunk-HX64QWB6.cjs.map