schematex 0.9.7 → 0.9.8

package/dist/{chunk-ECHPMEZX.cjs → chunk-2LVU75P3.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunk6X7MVZZT_cjs = require('./chunk-6X7MVZZT.cjs');
+var chunkBEPVTFXK_cjs = require('./chunk-BEPVTFXK.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -443,6 +443,43 @@ var DIAGRAM_REGISTRY = [
       "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 ────────────────────────────
   {
     type: "causalloop",
@@ -748,7 +785,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);
@@ -1141,6 +1180,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",
@@ -4613,6 +4705,10 @@ 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- **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`.'
   }
 };
 
@@ -5920,6 +6016,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"',
@@ -6311,7 +6450,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 = chunk6X7MVZZT_cjs.parseResult(dsl, config);
+  const result = chunkBEPVTFXK_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6337,7 +6476,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunk6X7MVZZT_cjs.renderResult(dsl, config);
+  const result = chunkBEPVTFXK_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -6399,5 +6538,5 @@ exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.resolveDiagramType = resolveDiagramType;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-ECHPMEZX.cjs.map
-//# sourceMappingURL=chunk-ECHPMEZX.cjs.map
+//# sourceMappingURL=chunk-2LVU75P3.cjs.map
+//# sourceMappingURL=chunk-2LVU75P3.cjs.map