schematex 0.9.6 → 0.9.8

package/dist/{chunk-CVTHUOAM.js → chunk-33BFUEYU.js}

@@ -1,4 +1,4 @@
-import { parseResult, renderResult } from './chunk-4W75FGWO.js';
+import { parseResult, renderResult } from './chunk-4QLIFOKH.js';
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -413,7 +413,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",
@@ -434,7 +434,48 @@ var DIAGRAM_REGISTRY = [
       "RAMS",
       "Birnbaum importance",
       "single point of failure",
-      "fault tolerance"
+      "fault tolerance",
+      "MTBF",
+      "Weibull",
+      "mission time reliability",
+      "reliability over time"
+    ]
+  },
+  {
+    type: "comparison",
+    name: "Comparison & Decision Matrix",
+    tagline: "One engine for compare-and-contrast \u2014 T-chart, pros/cons, comparison matrix, and the Pugh decision matrix that computes its own winner.",
+    useWhen: 'Use to put options side by side and, when there are weighted criteria, to *decide*. Header `comparison "Title"` (or `tchart` / `pugh`) with `mode:` \u2014 `tchart` (2\u2013N bullet columns, also Y-chart), `pros-cons` (green \u2713 / red \u2717 valence), `matrix` (options \xD7 criteria grid; cells take text or yes/no/partial marks), `decision`/`pugh` (criteria carry `weight:`, each option a numeric score, and the engine computes every option\'s weighted total \u03A3(w\xB7s), ranks them, and highlights the winner \u2014 Stuart Pugh / ASQ concept selection), or `double-bubble` (Thinking Maps compare/contrast: shared traits in the middle, unique ones fanning out). Distinct from `matrix` (the 2\xD72 / BCG / quadrant engine, which *positions* items on two axes) \u2014 this one lays out a *table* and computes the decision.',
+    cluster: "strategy",
+    standard: "Pugh, Total Design (1991) controlled convergence \xB7 ASQ decision matrix \xB7 Hyerle Thinking Maps (double-bubble) \xB7 K-12 graphic-organizer convention; see 51-COMPARISON-STANDARD.md",
+    syntaxKey: "comparison",
+    aliases: [
+      "comparison chart",
+      "comparison table",
+      "T-chart",
+      "Y-chart",
+      "pros and cons",
+      "pros/cons",
+      "decision matrix",
+      "Pugh matrix",
+      "weighted scoring matrix",
+      "double bubble map",
+      "compare and contrast",
+      "\u5BF9\u6BD4\u56FE",
+      "\u51B3\u7B56\u77E9\u9635"
+    ],
+    keywords: [
+      "compare options",
+      "concept selection",
+      "controlled convergence",
+      "weighted scoring",
+      "vendor selection",
+      "feature comparison",
+      "pros cons list",
+      "graphic organizer",
+      "Thinking Maps",
+      "decision making",
+      "trade study"
     ]
   },
   // ── Systems thinking / stochastic ────────────────────────────
@@ -742,7 +783,9 @@ var DIAGRAM_SINCE = {
   // 0.9.4 — multi-sport playbook (football X&O / basketball / soccer)
   playbook: "0.9.4",
   // 0.9.5 — reliability block diagram (IEC 61078)
-  rbd: "0.9.5"
+  rbd: "0.9.5",
+  // 0.9.8 — comparison & decision matrix (Pugh / pros-cons / T-chart / double-bubble)
+  comparison: "0.9.8"
 };
 function getDiagramSince(type) {
   const resolved = resolveDiagramType(type);
@@ -1135,6 +1178,59 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'circuit "Pull-up + push button" netlist\nV1 vcc 0 5V\nR1 vcc sig 10k dir=down\nSW1 sig 0 type=switch\nC1 sig 0 100n',
     "notes": "## Scenario\n\nAn embedded engineer documents a classic active-low input: a pull-up resistor\nholds the signal high, a push button pulls it to ground, and a small capacitor\ndebounces it. The connectivity is written as a SPICE-style netlist \u2014 the engine\nplaces everything from the node names \u2014 and one optional hint refines the look.\n\n## Annotation key\n\n- **netlist line** \u2014 `id node-A node-B value`; components that share a node name\n  are wired together. `0` is ground.\n- **`dir=down`** \u2014 the optional orientation hint. `R1` connects `vcc` to `sig`;\n  by default the engine would lay it horizontally, but a pull-up reads best drawn\n  vertically from the supply rail down to the signal node, so `dir=down` rotates\n  just that symbol. Connectivity is unchanged \u2014 `dir=` only rotates the glyph.\n- **`type=switch`** \u2014 the `SW1` id prefix is ambiguous, so the component type is\n  made explicit.\n\n## How to read\n\n`R1` ties `sig` up to `vcc` (drawn vertically thanks to `dir=down`). `SW1` and the\ndebounce cap `C1` both go from `sig` to ground, so the engine recognises them as\nshunt legs and drops them beneath the node. Pressing the button shorts `sig` to\nground, pulling the input low."
   },
+  {
+    "slug": "comparison-cell-double-bubble",
+    "diagram": "comparison",
+    "title": "Plant vs animal cell \u2014 double-bubble",
+    "description": "A Thinking-Maps double-bubble compare/contrast organizer \u2014 shared traits in the middle connected to both centres, unique traits fanning out.",
+    "standard": "Hyerle, Thinking Maps (1996)",
+    "tags": [
+      "comparison",
+      "double-bubble",
+      "thinking-maps",
+      "education",
+      "compare-contrast"
+    ],
+    "complexity": 1,
+    "featured": false,
+    "dsl": 'comparison "Plant cell vs Animal cell"\nmode: double-bubble\nleft "Plant cell"\nright "Animal cell"\nshared "Has a nucleus"\nshared "Mitochondria"\nshared "Cell membrane"\nleft-only "Cell wall"\nleft-only "Chloroplasts"\nleft-only "Large central vacuole"\nright-only "Centrioles"\nright-only "Lysosomes"\nright-only "Many small vacuoles"',
+    "notes": "## What this shows\n\nThe Double-Bubble Map is the standard Thinking-Maps organizer for compare/contrast. The two subjects sit as centres; **shared** attributes go in the middle column and connect to *both* centres; attributes unique to each side fan out and connect only to their own centre. The rigid five-column geometry is produced automatically \u2014 you just list what is shared and what is unique."
+  },
+  {
+    "slug": "comparison-cicd-decision-matrix",
+    "diagram": "comparison",
+    "title": "CI/CD platform \u2014 decision matrix",
+    "description": "A Pugh weighted-decision matrix where the engine computes each option's weighted total, ranks them, and highlights the winner \u2014 with Jenkins as the datum baseline.",
+    "standard": "Pugh, Total Design (1991) \xB7 ASQ decision matrix",
+    "tags": [
+      "comparison",
+      "decision-matrix",
+      "pugh",
+      "weighted-scoring",
+      "trade-study"
+    ],
+    "complexity": 3,
+    "featured": true,
+    "dsl": 'comparison "Selecting a CI/CD platform"\nmode: decision\nbaseline: "Jenkins"\noption "GitHub Actions"\noption "GitLab CI"\noption "CircleCI"\noption "Jenkins"\ncriterion "Ease of setup" weight: 5\n  GitHub Actions: 5\n  GitLab CI: 4\n  CircleCI: 4\n  Jenkins: 2\ncriterion "Build speed" weight: 4\n  GitHub Actions: 4\n  GitLab CI: 4\n  CircleCI: 5\n  Jenkins: 3\ncriterion "Cost at our scale" weight: 4\n  GitHub Actions: 4\n  GitLab CI: 3\n  CircleCI: 3\n  Jenkins: 5\ncriterion "Ecosystem / marketplace" weight: 3\n  GitHub Actions: 5\n  GitLab CI: 3\n  CircleCI: 3\n  Jenkins: 4\ncriterion "Self-host control" weight: 2\n  GitHub Actions: 2\n  GitLab CI: 5\n  CircleCI: 2\n  Jenkins: 5',
+    "notes": '## What this shows\n\nThis is the engine\'s differentiator. You declare the **options** (columns), the weighted **criteria** (rows), and a score per cell \u2014 and you stop there. The **Weighted total** row, the `#1`\u2026`#4` ranks, the green winner, and the **vs datum** deltas against Jenkins are all *computed* (\u03A3 of weight \xD7 score), not typed in. Change one score and the winner can flip. That is Stuart Pugh\'s controlled-convergence method \u2014 the same "the engine computes the answer" stance as `pert` (schedule) and `faulttree` (cut sets).\n\nThe `baseline: "Jenkins"` line marks the Pugh datum: that column is shaded and every other option shows its margin over it.'
+  },
+  {
+    "slug": "comparison-cloud-feature-matrix",
+    "diagram": "comparison",
+    "title": "Cloud providers \u2014 feature comparison matrix",
+    "description": "An options \xD7 criteria comparison grid mixing yes/partial marks with free-text cells \u2014 the kind of feature table no quadrant chart can express.",
+    "standard": "ASQ comparison matrix \xB7 graphic-organizer convention",
+    "tags": [
+      "comparison",
+      "matrix",
+      "feature-comparison",
+      "cloud"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'comparison "Cloud provider \u2014 managed services"\nmode: matrix\noption "AWS"\noption "GCP"\noption "Azure"\ncriterion "Free tier"\n  AWS: "12 months"\n  GCP: "Always-free"\n  Azure: "12 months"\ncriterion "Managed Postgres"\n  AWS: yes\n  GCP: yes\n  Azure: yes\ncriterion "Serverless GPU"\n  AWS: partial\n  GCP: yes\n  Azure: partial\ncriterion "Spot discount"\n  AWS: "up to 90%"\n  GCP: "up to 91%"\n  Azure: "up to 90%"\ncriterion "On-prem hybrid"\n  AWS: partial\n  GCP: partial\n  Azure: yes',
+    "notes": '## What this shows\n\nA straight side-by-side feature table \u2014 options across the top, criteria down the side. Cells mix **marks** (`yes` \u2192 \u2713 green, `partial` \u2192 ~ amber) with **free text** (`"up to 90%"`), so one grid carries both capability flags and figures. The option name on each cell line must match a declared `option`; a typo is flagged in the diagnostics rather than silently dropped.'
+  },
   {
     "slug": "decisiontree-influence-market-entry",
     "diagram": "decisiontree",
@@ -3607,6 +3703,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",
@@ -4586,7 +4702,11 @@ 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.'
+  },
+  "comparison": {
+    "title": "Comparison & Decision Matrix",
+    "content": '## 1. Header and mode\n\nThe header keyword is `comparison` (aliases `compare`, `vs`). The header keywords `tchart` and `pugh` set the mode directly. Otherwise choose with the `mode:` directive:\n\n```\ncomparison "Title"\nmode: tchart | pros-cons | matrix | decision | double-bubble\nlegend: on | off\n```\n\nIf you omit `mode:`, it is inferred from the keywords you use \u2014 but generating it explicitly is more reliable.\n\n## 2. T-chart (and Y-chart)\n\nDeclare each `column`, then list its points with `-` bullets. Three columns reads as a Y-chart.\n\n```\ntchart "TCP vs UDP"\ncolumn "TCP"\n- Connection-oriented (handshake)\n- Guaranteed, ordered delivery\ncolumn "UDP"\n- Connectionless, fire-and-forget\n- Minimal header, low latency\n```\n\n## 3. Pros / cons\n\n```\ncomparison "Migrate to microservices?"\nmode: pros-cons\npro "Independent team deploys"\npro "Scale hot paths in isolation"\ncon "Distributed-systems complexity"\ncon "Operational + infra cost goes up"\n```\n\n`pro` lines fill the green column, `con` the red \u2014 order independent.\n\n## 4. Comparison matrix\n\nDeclare every `option` (the columns), then each `criterion` (a row) with one indented `OptionName: value` cell per option. Cell values: `yes` / `no` / `partial` render as \u2713 / \u2717 / ~, numbers are scores, quoted text is shown verbatim. The option name must match an `option` exactly (a typo is flagged, not dropped).\n\n```\ncomparison "Cloud provider \u2014 managed services"\nmode: matrix\noption "AWS"\noption "GCP"\noption "Azure"\ncriterion "Free tier"\n  AWS: "12 months"\n  GCP: "Always-free"\n  Azure: "12 months"\ncriterion "Managed Postgres"\n  AWS: yes\n  GCP: yes\n  Azure: partial\n```\n\nA compact pipe form is also accepted: `criterion "Free tier" | "12 months" | "Always-free" | "12 months"` (positional to option order).\n\n## 5. Decision matrix (computed)\n\nAdd a `weight:` to each criterion and a numeric score to each cell. The engine appends a **Weighted total** row, ranks the options (`#1`, `#2`, \u2026), and highlights the winner. Add `baseline: "Option"` for a Pugh datum \u2014 that column is shaded and a **vs datum** delta row is added.\n\n```\npugh "Database for the new service"\nbaseline: "PostgreSQL"\noption "PostgreSQL"\noption "MongoDB"\noption "DynamoDB"\ncriterion "Query flexibility" weight: 5\n  PostgreSQL: 5\n  MongoDB: 3\n  DynamoDB: 2\ncriterion "Horizontal scaling" weight: 4\n  PostgreSQL: 3\n  MongoDB: 4\n  DynamoDB: 5\ncriterion "Operational cost" weight: 3\n  PostgreSQL: 4\n  MongoDB: 3\n  DynamoDB: 3\n```\n\nYou never write the totals \u2014 the engine computes \u03A3(weight \xD7 score), so getting a score wrong changes the computed winner.\n\n## 6. Double-bubble (compare & contrast)\n\n```\ncomparison "Plant cell vs Animal cell"\nmode: double-bubble\nleft "Plant cell"\nright "Animal cell"\nshared "Has a nucleus"\nshared "Mitochondria"\nleft-only "Cell wall"\nleft-only "Chloroplasts"\nright-only "Centrioles"\nright-only "Lysosomes"\n```\n\n`shared` traits sit in the middle, connected to both centres; `left-only` / `right-only` fan out to their own centre.\n\n## 7. Themes\n\n`default` is the house blue with green/red/amber valence; `monochrome` drops colour (valence rides on \u2713/\u2717/~, the winner on a heavy border) for B&W print; `dark` is Catppuccin.\n\n## Standard\n\nPugh, *Total Design* (1991) controlled convergence \xB7 ASQ decision matrix \xB7 Hyerle Thinking Maps (double-bubble) \xB7 K-12 graphic-organizer convention. See `docs/reference/51-COMPARISON-STANDARD.md`.'
   }
 };
 
@@ -5859,7 +5979,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 {",
@@ -5880,7 +6000,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.",
@@ -5893,6 +6014,49 @@ var PROFILES = {
       "If system reliability shows 'n/a', a block is missing its `R=`/`p=`."
     ]
   },
+  comparison: {
+    type: "comparison",
+    header: 'comparison "Title"',
+    mode: "one DSL, five modes selected by `mode:` \u2014 pick the mode that matches the task",
+    keywords: 'comparison "Title" (alias headers: tchart | pugh) \xB7 mode: tchart | pros-cons | matrix | decision | double-bubble \xB7 legend: on|off \xB7 tchart: column "X" then `- item` bullets \xB7 pros-cons: pro "\u2026" / con "\u2026" \xB7 matrix & decision: option "A" (columns) + criterion "X" [weight: N] (rows) with indented `A: value` cells (value = text | yes/no/partial | number) \xB7 decision adds numeric scores + optional baseline: "A" (Pugh datum) \u2192 engine computes weighted total, rank, winner \xB7 double-bubble: left "A" / right "B" / shared "\u2026" / left-only "\u2026" / right-only "\u2026"',
+    forms: [
+      'comparison "Database choice"',
+      "mode: decision",
+      'option "PostgreSQL"',
+      'option "MongoDB"',
+      'criterion "Query flexibility" weight: 5',
+      "  PostgreSQL: 5",
+      "  MongoDB: 3",
+      'criterion "Horizontal scaling" weight: 4',
+      "  PostgreSQL: 3",
+      "  MongoDB: 5",
+      "# \u2014 or a simple T-chart \u2014",
+      "mode: tchart",
+      'column "Remote"',
+      "- No commute",
+      'column "Office"',
+      "- Easier collaboration"
+    ],
+    prefer: [
+      "Choose the mode by the job: 2\u2013N bullet columns \u2192 `tchart`; a green/red list \u2192 `pros-cons`; an options\xD7criteria table of facts \u2192 `matrix`; a *decision* with weighted scores \u2192 `decision` (alias `pugh`); a compare/contrast organizer \u2192 `double-bubble`.",
+      "In `matrix`/`decision`, declare every `option` first, then each `criterion`, then indent the per-option cells as `OptionName: value` (the name must match an `option` exactly).",
+      "Use `decision` whenever the user wants to *pick a winner*: give each criterion a `weight:` and each option a numeric score \u2014 the engine sums \u03A3(weight\xD7score), ranks, and highlights the winner. Don't compute the totals yourself.",
+      "Cell marks: `yes`/`no`/`partial` render as \u2713/\u2717/~; numbers are scores; quoted text is shown verbatim.",
+      'For a Pugh datum, add `baseline: "OptionName"` \u2014 the engine shades that column and shows each option\'s delta versus it.'
+    ],
+    avoid: [
+      "Don't reach for `comparison` to plot items on two axes (Eisenhower / BCG / impact-effort) \u2014 that's the `matrix` diagram. `comparison` is a table, not a quadrant.",
+      "Don't write cell lines before declaring the options \u2014 an unknown `Name:` cell is dropped with a warning.",
+      "Don't hand-write a 'Total' row in `decision` mode \u2014 the engine appends and ranks it.",
+      "Don't mix modes in one document; set exactly one `mode:`."
+    ],
+    repair: [
+      "'is not a declared option' -> add `option \"Name\"` or fix the cell's name to match an option.",
+      "'needs at least one option/criterion' -> a matrix needs both `option` columns and `criterion` rows.",
+      "'no numeric scores found' (decision) -> add `Option: <number>` cells, or switch to `mode: matrix`.",
+      '\'needs both a left and a right\' (double-bubble) -> declare `left "A"` and `right "B"`.'
+    ]
+  },
   causalloop: {
     type: "causalloop",
     header: 'causalloop "Title"',
@@ -6362,5 +6526,5 @@ function matchRepair(repairs, message) {
 }
 
 export { DIAGRAM_REGISTRY, DIAGRAM_SINCE, getAllDiagramTypes, getDiagramMeta, getDiagramSince, getExamples, getSyntax, listDiagrams, renderDsl, resolveDiagramType, validateDsl };
-//# sourceMappingURL=chunk-CVTHUOAM.js.map
-//# sourceMappingURL=chunk-CVTHUOAM.js.map
+//# sourceMappingURL=chunk-33BFUEYU.js.map
+//# sourceMappingURL=chunk-33BFUEYU.js.map