schematex 0.9.5 → 0.9.7

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

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkQ7CWX6HA_cjs = require('./chunk-Q7CWX6HA.cjs');
+var chunk6X7MVZZT_cjs = require('./chunk-6X7MVZZT.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 ───────────────────────────────────────────
   {
@@ -393,7 +415,7 @@ var DIAGRAM_REGISTRY = [
     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.',
+    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). For reliability over a mission, add `mission: <t>` and give blocks a distribution \u2014 `rate=\u03BB`/`mtbf=N` (exponential) or `weibull=\u03B2,\u03B7` \u2014 and the engine evaluates R(t). 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",
@@ -414,7 +436,11 @@ var DIAGRAM_REGISTRY = [
       "RAMS",
       "Birnbaum importance",
       "single point of failure",
-      "fault tolerance"
+      "fault tolerance",
+      "MTBF",
+      "Weibull",
+      "mission time reliability",
+      "reliability over time"
     ]
   },
   // ── Systems thinking / stochastic ────────────────────────────
@@ -2054,6 +2080,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",
@@ -3548,6 +3613,26 @@ A textbook fly-by-wire architecture, the kind certified under ARP4761: **2-out-o
 
 **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-pump-station-mission",
+    "diagram": "rbd",
+    "title": "Pump station reliability over a 1-year mission (R(t))",
+    "description": "A reliability block diagram evaluated at a mission time \u2014 two redundant pumps with exponential (MTBF) and Weibull failure distributions. The engine computes R(t) for each block from its distribution and rolls it up to the system reliability at t = 8760 hours.",
+    "standard": "IEC 61078 (RBD) + IEC 61810 / MIL-HDBK-217 (R(t))",
+    "tags": [
+      "rbd",
+      "reliability",
+      "mission-time",
+      "mtbf",
+      "weibull",
+      "redundancy",
+      "availability"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'rbd "Pump Station \u2014 1-year mission"\n  mission: 8760\n  series {\n    block CTRL "Controller" mtbf=50000\n    parallel {\n      block A "Pump A" mtbf=10000\n      block B "Pump B" weibull=1.5,12000\n    }\n  }',
+    "notes": "## What this shows\n\nStatic reliabilities are the entry point; real RAMS work is **reliability over a mission**. Here `mission: 8760` (one year in hours) turns each block's failure distribution into an **R(t)**: the controller and Pump A use an exponential model from their **MTBF**, while Pump B uses a **Weibull** (\u03B2 = 1.5, so a gently increasing hazard \u2014 wear-out).\n\n**The engine evaluates R(t) per block and composes it.** Pump A's `e^(\u22128760/10000) \u2248 0.42` and Pump B's `e^(\u2212(8760/12000)^1.5) \u2248 0.54` combine in parallel to \u2248 0.73, then multiply by the controller in series \u2014 the headline reads `R(t=8760) = \u2026`. Change the mission time and every figure, and the importance ranking, recomputes. Constant `R=` blocks still work and mix freely with distributions."
+  },
   {
     "slug": "rbd-redundant-server",
     "diagram": "rbd",
@@ -4459,7 +4544,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",
@@ -4527,7 +4612,7 @@ var SYNTAX = {
   },
   "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.'
+    "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- **Criticality importance** `I_C(i) = I\u1D2E(i)\xB7(1\u2212R\u1D62)/(1\u2212R_sys)` \u2014 the probability block i is failed *and* critical, given the system is failed.\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. Time-dependent reliability \u2014 R(t)\n\nA static `R=` is the entry point; in practice reliability is a function of mission time. Set a **`mission: <t>`** and give blocks a failure distribution instead of a constant \u2014 the engine evaluates **R(t)** and rolls it up exactly as before. Use **consistent time units** across `mission` and the rates.\n\n| Block attribute | Model | R(t) |\n|-----------------|-------|------|\n| `rate=0.0001` | exponential (constant hazard \u03BB) | e^(\u2212\u03BBt) |\n| `mtbf=10000` | exponential (\u03BB = 1/MTBF) | e^(\u2212t/MTBF) |\n| `weibull=2,10000` | Weibull(\u03B2 shape, \u03B7 scale) | e^(\u2212(t/\u03B7)^\u03B2) |\n\n```\nrbd "Pump station \u2014 1-year mission"\n  mission: 8760            # hours\n  parallel {\n    block A "Pump A" mtbf=10000\n    block B "Pump B" weibull=1.5,12000\n  }\n```\n\nThe headline becomes `R(t=8760) = \u2026`. A block with a distribution but no `mission:` warns and falls back to its constant `R=` (if any).\n\n## 6. 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## 7. 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.'
   }
 };
 
@@ -5510,9 +5595,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"',
@@ -5523,12 +5608,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.",
@@ -5791,7 +5885,7 @@ var PROFILES = {
     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',
+    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, R=99%) \xB7 time-dependent: mission: <t> + block rate=\u03BB | mtbf=N | weibull=\u03B2,\u03B7 \u2192 R(t) \xB7 engine computes system reliability + Birnbaum & criticality importance + SPOF',
     forms: [
       'rbd "Redundant Server"',
       "series {",
@@ -5812,7 +5906,8 @@ var PROFILES = {
       "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."
+      "A bare top-level list of blocks (no outer group) is treated as a series chain.",
+      "For reliability over a mission, add `mission: <t>` and give blocks a distribution \u2014 `rate=\u03BB` or `mtbf=N` (exponential) or `weibull=\u03B2,\u03B7` \u2014 and the engine computes R(t); keep mission and rates in the same time units."
     ],
     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.",
@@ -6216,7 +6311,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 = chunkQ7CWX6HA_cjs.parseResult(dsl, config);
+  const result = chunk6X7MVZZT_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6242,7 +6337,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunkQ7CWX6HA_cjs.renderResult(dsl, config);
+  const result = chunk6X7MVZZT_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6304,5 +6399,5 @@ exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.resolveDiagramType = resolveDiagramType;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-7EWP4OD7.cjs.map
-//# sourceMappingURL=chunk-7EWP4OD7.cjs.map
+//# sourceMappingURL=chunk-ECHPMEZX.cjs.map
+//# sourceMappingURL=chunk-ECHPMEZX.cjs.map