schematex 0.2.5 → 0.3.0

package/dist/{chunk-MR5HU5WU.js → chunk-VLMK7MQK.js}

@@ -1,4 +1,4 @@
-import { parse, render } from './chunk-VPKCW4PB.js';
+import { parse, render } from './chunk-NNU4RGT3.js';
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -103,6 +103,15 @@ var DIAGRAM_REGISTRY = [
     standard: "IEEE Std 315 + ANSI device numbering",
     syntaxKey: "sld"
   },
+  {
+    type: "pid",
+    name: "P&ID (Piping & Instrumentation)",
+    tagline: "ISA-5.1 process equipment, valves, and instrument bubbles.",
+    useWhen: "Use for chemical / petrochemical / pharmaceutical / water-treatment process diagrams \u2014 vessels, columns, heat exchangers, pumps, valves, and instrument loops with ISA tag codes (FT/FIC/PT/etc.). Equipment + piping + instrumentation in one diagram.",
+    cluster: "electrical-industrial",
+    standard: "ANSI/ISA-5.1-2009 + ISO 10628-1:2014",
+    syntaxKey: "pid"
+  },
   // ── Corporate / Legal ────────────────────────────────────────
   {
     type: "entity",
@@ -141,6 +150,16 @@ var DIAGRAM_REGISTRY = [
     standard: "Howard-Raiffa / CART-sklearn / taxonomy",
     syntaxKey: "decisiontree"
   },
+  // ── Behavior modeling ────────────────────────────────────────
+  {
+    type: "state",
+    name: "State diagram",
+    tagline: "UML 2.5 / Harel statechart with composite states and pseudo-states.",
+    useWhen: "Use for modeling reactive system behavior \u2014 finite state machines, lifecycle states, controller modes, UI workflows. Supports simple states, composite (nested) states, fork/join, choice, history, and full Mermaid `stateDiagram-v2` syntax.",
+    cluster: "behavior-modeling",
+    standard: "OMG UML 2.5.1 \xA714 + Harel (1987) statechart",
+    syntaxKey: "state"
+  },
   // ── Generic process / flow ───────────────────────────────────
   {
     type: "flowchart",
@@ -996,6 +1015,14 @@ var SYNTAX = {
   "timeline": {
     "title": "Timeline diagram",
     "content": '## 1. Your first timeline\n\nThe smallest useful timeline: a title, two ordinary events, and a milestone.\n\n```\ntimeline "Product Launch"\n2024-06-01: "Development complete"\n2024-08-15: "Closed beta"\n2024-09-01: milestone "Public launch"\n```\n\nFour rules cover 80% of usage:\n\n1. Start with the keyword `timeline`, optionally followed by a quoted title.\n2. Each event is `DATE: "Label"` \u2014 a date, a colon, then a quoted label. A `milestone` keyword before the label marks the event as a milestone.\n3. Date ranges use `DATE - DATE:` or `DATE .. DATE:` (both are equivalent).\n4. Add `[key: value]` properties after the quoted label to set color, side placement, shape, or category.\n\n> Comments must start with `#` or `//` on their own line.\n\n---\n\n## 2. Events\n\nAn event line places a labeled marker at a point in time (or a bar across a span).\n\n### 2.1 Point events\n\n```\n2024-09-15: "Conference keynote"\n```\n\n### 2.2 Range events\n\n```\n2024-06-01 - 2024-08-31: "Q3 development sprint"\n2024-06-01 .. 2024-08-31: "Q3 development sprint"\n```\n\nBoth separators (`-` surrounded by spaces, or `..`) are equivalent.\n\n### 2.3 Milestones\n\n```\n2024-09-01: milestone "Public launch"\n```\n\nThe `milestone` keyword before the quoted label switches the marker to a diamond shape.\n\n### 2.4 Event properties\n\nProperties go in `[key: value, \u2026]` after the quoted label, before the newline.\n\n| Property | Values | Meaning |\n|---|---|---|\n| `color:` | hex string | Custom color for this marker or bar |\n| `side:` | `above` \\| `below` | Force placement above or below the axis (swimlane / lollipop) |\n| `icon:` | any text (e.g. emoji) | Icon displayed with the event |\n| `shape:` | `circle` \\| `square` \\| `diamond` \\| `star` \\| `flag` | Point marker shape |\n| `category:` | quoted string | Group label \u2014 drives color in gantt legend |\n\n```\n2024-09-01: milestone "Launch day" [color: #E53935, side: above]\n2024-07-15: "Beta ships" [icon: \u{1F680}, category: "product"]\n```\n\n```\ntimeline "Engineering Milestones"\nconfig: style = lollipop\n\n2024-01-08: "Sprint planning complete"\n2024-02-14: milestone "Design system shipped" [side: above, color: #1565C0]\n2024-03-22: "Incident \u2014 4h outage" [icon: \u26A0\uFE0F]\n2024-04-01 - 2024-06-30: "API v2 build"\n2024-07-01: milestone "API v2 GA" [side: above, color: #2E7D32]\n```\n\n---\n\n## 3. Date formats\n\nAll date formats can appear anywhere a date is expected \u2014 in events, eras, and ranges.\n\n| Format | Example | Notes |\n|---|---|---|\n| Full date | `2024-09-15` | Day-precision; `YYYY-MM-DD` |\n| Year-month | `2024-09` | Month-precision |\n| Year | `2024` | Year-precision |\n| Quarter | `2024-Q3` | Maps to start of that quarter |\n| BC year (negative) | `-753` | 753 BC |\n| BC year (suffix) | `753BC` or `753BCE` | Same as `-753` |\n| Geological | `65Ma`, `4.6Ga`, `12ka` | Million / billion / thousand years ago |\n\n```\ntimeline "Age of Earth"\nconfig: style = lollipop\nconfig: scale = log\n\n4600Ma: "Earth forms"\n540Ma: "Cambrian explosion"\n252Ma: milestone "Permian extinction \u2014 96% of species lost"\n66Ma: milestone "K-Pg extinction \u2014 end of non-avian dinosaurs"\n3Ma: "Earliest stone tools (Lomekwi)"\n0: "Present day"\n```\n\n---\n\n## 4. Eras (background spans)\n\nAn `era` line draws a shaded background band across the time axis. It always requires a date range.\n\n```\nera 2020 - 2022: "Foundation Phase"\nera 2022 .. 2025: "Growth Phase" [color: #E8F5E9]\n```\n\nThe `[color: \u2026]` property is optional. Overlapping eras stack into separate bands automatically.\n\n```\ntimeline "Company History"\nconfig: style = swimlane\n\nera 2019..2021: "Early Stage" [color: #FFF8E1]\nera 2021..2024: "Series A & B" [color: #E8F5E9]\n\n2019-03-01: "Founded"\n2019-11-15: "First paying customer"\n2020-05-01: milestone "Product-market fit" [side: above]\n2021-02-10: "Series A \u2014 $8M"\n2022-09-01: "Series B \u2014 $30M"\n2023-06-15: milestone "Profitability" [color: #1B5E20]\n```\n\n---\n\n## 5. Tracks (swimlane grouping)\n\nA `track` block groups related events into a named swimlane. Indented event lines (2 spaces) belong to the track.\n\n```\ntrack "Engineering":\n  2024-01-15 - 2024-03-31: "API design"\n  2024-04-01 - 2024-07-31: "Implementation"\n\ntrack "Marketing":\n  2024-06-01: "Campaign kick-off"\n  2024-09-01: milestone "Launch campaign" [color: #1B5E20]\n```\n\nTracks are most useful in `gantt` style, where each track becomes its own labeled row.\n\n```\ntimeline "Q3 Project Plan"\nconfig: style = gantt\n\ntrack "Backend":\n  2024-07-01 - 2024-08-15: "Database migration"\n  2024-08-16 - 2024-09-30: "API hardening"\n\ntrack "Frontend":\n  2024-07-01 - 2024-08-31: "New design system"\n  2024-09-01 - 2024-09-30: "Integration & QA"\n\ntrack "DevOps":\n  2024-07-15 - 2024-08-01: "Staging environment"\n  2024-09-30: milestone "Go-live" [color: #2E7D32]\n```\n\n---\n\n## 6. Notes\n\nA `note:` line indented under an event attaches a tooltip annotation to it.\n\n```\n2024-06-01: "Beta launch"\n  note: "First external users; NPS target 40+"\n```\n\nNotes work both for flat events and for events inside tracks.\n\n---\n\n## 7. Configuration\n\n`config:` lines tune the layout and visual style. Each is its own line in the form `config: key = value`.\n\n| Key | Values | Default | Effect |\n|---|---|---|---|\n| `style` | `swimlane` \\| `gantt` \\| `lollipop` | `swimlane` | Visual rendering mode |\n| `orientation` | `horizontal` \\| `vertical` | `horizontal` | Axis direction |\n| `scale` | `proportional` \\| `equidistant` \\| `log` | `proportional` | How time maps to screen space |\n| `axis` | `bottom` \\| `center` | `bottom` | Where the time axis is drawn |\n\n**Style notes:**\n- `swimlane` \u2014 events alternate above and below a horizontal axis; `side:` controls per-event placement. Eras add colored background bands. Best for roadmaps and biographies.\n- `gantt` \u2014 each named track becomes a horizontal bar lane; milestones become pins above the bars. `gantt-project` is an alias. Best for project scheduling.\n- `lollipop` \u2014 a center axis with labeled cards on alternating stems. Best for historical retrospectives with sparse, memorable events.\n\n**Swimlane** \u2014 roadmaps, product timelines, biographies. Eras add color bands; events alternate above and below.\n\n```\ntimeline "SaaS Platform Roadmap"\nconfig: style = swimlane\n\nera 2024-Q1..2024-Q2: "Foundation" [color: #E3F2FD]\nera 2024-Q3..2024-Q4: "Growth" [color: #E8F5E9]\n\n2024-01-15: "Kick-off & team onboarding"\n2024-02-01: milestone "Architecture sign-off" [side: above]\n2024-03-01 - 2024-05-31: "API v2 build"\n2024-04-10: "Security audit" [color: #F9A825]\n2024-06-30: milestone "Beta launch" [side: above]\n2024-07-01 - 2024-09-30: "Performance & scaling"\n2024-10-15: milestone "General availability" [color: #2E7D32]\n```\n\n**Gantt** \u2014 parallel tracks with horizontal duration bars and milestone pins. Best for project scheduling.\n\n```\ntimeline "Product Launch \u2014 Q4"\nconfig: style = gantt\n\ntrack "Engineering":\n  2024-10-01 - 2024-11-15: "Feature freeze & hardening"\n  2024-11-16 - 2024-11-30: "Load testing"\n\ntrack "Design":\n  2024-10-01 - 2024-10-31: "Final UI polish"\n  2024-11-01 - 2024-11-14: "Asset delivery"\n\ntrack "Marketing":\n  2024-10-15 - 2024-11-14: "Campaign prep"\n  2024-11-15 - 2024-11-30: "Launch campaign"\n  2024-12-01: milestone "Launch day" [color: #2E7D32]\n```\n\n**Lollipop** \u2014 sparse milestones on a centered axis with alternating cards. Best for historical retrospectives and brand stories.\n\n```\ntimeline "History of Computing"\nconfig: style = lollipop\nconfig: scale = equidistant\n\n1936: "Turing \u2014 On Computable Numbers"\n1945: "ENIAC \u2014 first general-purpose computer"\n1969: "ARPANET"\n1971: milestone "Intel 4004 microprocessor" [side: above]\n1976: "Apple I"\n1991: "World Wide Web (Berners-Lee)"\n2007: milestone "iPhone" [color: #1565C0, side: above]\n```\n\n---\n\n## 8. Labels & comments\n\n- **Title:** `timeline "My Title"` \u2014 first line only.\n- **Event label:** quoted string after the colon: `DATE: "Label"`.\n- **Milestone label:** `DATE: milestone "Label"`.\n- **Era label:** `era DATE - DATE: "Label"`.\n- **Track name:** `track "Name":`.\n- **Note:** `note: "text"` indented under an event.\n- **Comments:** `#` or `//` at the start of a line (after leading whitespace).\n\n---\n\n## 9. Reserved words & escaping\n\n**Reserved at line start:** `timeline` (header), `config:`, `era`, `track`, `note:`.\n\n**Date range separators:** ` - ` (space-hyphen-space) and `..` \u2014 avoid these sequences inside label text that appears before the colon.\n\n**BC years as negative integers:** `-753` is the year 753 BC. The parser distinguishes the negative sign from a range separator by checking for surrounding whitespace \u2014 ` - ` (with spaces) is a range; `-753` (no leading space after a colon) is a BC year.\n\n**Property blocks:** `[key: value]` must appear *after* the quoted label on the same line. The closing `]` must be present; unclosed brackets produce a parse error.\n\n---\n\n## 10. Common mistakes\n\n| You wrote | Parser says | Fix |\n|---|---|---|\n| `2024-06-01: Launch day` (unquoted label) | Line not recognized as an event \u2014 `TimelineParseError` | Quote the label: `2024-06-01: "Launch day"` |\n| `2024-06 - 2024-09: "Q3"` (year-month range) | Parsed correctly | This works \u2014 all date formats are valid in ranges |\n| `era 2024: "Whole year"` (no range) | `TimelineParseError: era requires a date range` | Use a range: `era 2024 - 2024: "Whole year"` |\n| `track "Backend"` (no colon) | `TimelineParseError: Expected \':\' after track name` | Add the colon: `track "Backend":` |\n| `2024-01-01: "Event" [side: left]` | `side: left` silently ignored; only `above` and `below` are valid | Use `side: above` or `side: below` |\n| `config: style = Gantt` (capital G) | `TimelineParseError: Invalid style: Gantt` | Use lowercase: `config: style = gantt` |\n| `2024-01-01-2024-03-31: "Q1"` (no spaces around `-`) | Parser reads `2024-01-01-2024` as a date \u2014 fails | Use spaces: `2024-01-01 - 2024-03-31:` or `..`: `2024-01-01..2024-03-31:` |\n| Indented event without a track | Indented lines under the timeline header that aren\'t inside a `track` block \u2014 parsed as flat events | Only indent events that are inside a `track "Name":` block |\n\n---\n\n## 11. Grammar (EBNF)\n\n```text\ndocument     = header ( blank | comment | config | era | track | event )*\n\nheader       = "timeline" ( WS quoted-string )? NEWLINE\nquoted-string = \'"\' any-char-but-quote* \'"\'\n\nconfig       = "config:" WS key WS "=" WS value NEWLINE\nkey          = "style" | "orientation" | "scale" | "axis"\n\nera          = "era" WS date-range ":" WS quoted-string ( WS props )? NEWLINE\ntrack        = "track" WS quoted-string ":" NEWLINE\n                 ( INDENT\u22652 event | INDENT\u22652 note )*\n\nevent        = date-spec ":" WS event-body ( WS props )? NEWLINE\n               ( INDENT note )?\nevent-body   = ( "milestone" WS )? quoted-string\ndate-spec    = date ( ( " - " | ".." ) date )?\n\nnote         = "note:" WS quoted-string NEWLINE\n\nprops        = "[" prop-list "]"\nprop-list    = prop ( "," prop )*\nprop         = key ":" WS value\n             | key ":" WS quoted-string\n\ndate         = iso-date | year-month | year | quarter | bc-year | geological\niso-date     = digit{4} "-" digit{2} "-" digit{2}\nyear-month   = digit{4} "-" digit{2}\nyear         = "-"? digit{1,5}\nquarter      = digit{4} "-"? "Q" [1-4]\nbc-year      = digit+ ( "BC" | "BCE" )\ngeological   = number ( "Ma" | "Ga" | "ka" )\n\ncomment      = ( "#" | "//" ) any NEWLINE\n```\n\nAuthoritative source: `src/diagrams/timeline/parser.ts`. If this diverges from the parser, the parser wins \u2014 please open an issue.\n\n---'
+  },
+  "state": {
+    "title": "State diagram",
+    "content": '## 1. Your first state diagram\n\nThe smallest useful state diagram has an initial state, a final state, and one transition.\n\n```\nstateDiagram-v2\n[*] --> Running\nRunning --> [*] : done\n```\n\nThree rules cover 80% of usage:\n\n1. Start with `stateDiagram-v2` (Mermaid-style) or `state` (Schematex-style) header.\n2. Use `[*]` for the implicit start node (when on the left of `-->`) or end node (when on the right).\n3. Connect states with `-->`. Add a label after `:` \u2014 full UML form is `trigger [guard] / action`.\n\nThe default direction is **TB** (top-to-bottom) to match Mermaid. Override with `direction LR` on its own line, or `[direction: LR]` on the header.\n\n> Comments use `%%` (Mermaid), `#`, or `//`.\n\n---\n\n## 2. State declarations\n\nStates are auto-created when first referenced in a transition, but explicit declarations let you control the label and shape.\n\n```\nstate Authenticating\nstate "Awaiting Approval" as Approval\nIdle: Waiting for input\n```\n\n| Form | Effect |\n|---|---|\n| `Idle` | Bare ID \u2014 created as a simple state with `Idle` as both id and label |\n| `state Idle` | Explicit declaration; same effect |\n| `state "Awaiting Approval" as Approval` | Aliased \u2014 display `Awaiting Approval`, refer to it by `Approval` in transitions |\n| `Idle: Waiting for input` | Inline label \u2014 `Idle` is the id, `Waiting for input` is the visible label |\n\n---\n\n## 3. Pseudo-states\n\nPseudo-states control the flow of a state machine without representing a stable resting state.\n\n| Mermaid | Schematex | Symbol | Purpose |\n|---|---|---|---|\n| `[*]` (source) | `initial id` | Filled black circle | Entry point of a region |\n| `[*]` (target) | `final id` | Filled circle inside outer ring | Successful exit |\n| `state X <<choice>>` | `choice X` | Diamond | Dynamic branch (guards evaluated at runtime) |\n| `state X <<fork>>` | `fork X` | Thick black bar | One-input \u2192 N parallel outputs |\n| `state X <<join>>` | `join X` | Thick black bar | N inputs \u2192 one output |\n| \u2014 | `junction X` | Small filled circle | Static merge point |\n| \u2014 | `history X` | Circle with `H` | Re-enter at last visited sub-state |\n| \u2014 | `dhistory X` | Circle with `H*` | Deep history (recursive) |\n| \u2014 | `terminate X` | `\xD7` mark | Abnormal termination (no cleanup) |\n| \u2014 | `entry_point X` / `exit_point X` | Hollow circle on composite border | Named entry / exit points |\n\n`[*]` is the Mermaid alias and is always direction-resolved: on the **source** side of `-->` it\'s an `initial`, on the **target** side it\'s a `final`. Each composite scope gets its own pair.\n\n```\nstateDiagram-v2\n[*] --> Idle\nstate Decide <<choice>>\nstate Joiner <<join>>\nIdle --> Decide : evaluate\nDecide --> Authorized : [role == "admin"]\nDecide --> Joiner    : [role == "user"]\nAuthorized --> Joiner\nJoiner --> [*]\n```\n\n---\n\n## 4. Transitions\n\nThe full UML 2.5 transition label has three optional parts:\n\n```\ntrigger [guard] / action\n```\n\n| Field | Meaning | Example |\n|---|---|---|\n| `trigger` | Event that fires the transition | `submit`, `tick`, `timeout(30s)` |\n| `[guard]` | Boolean expression evaluated at trigger time | `[count > 0]`, `[role == "admin"]` |\n| `/ action` | Action(s) executed when transition is taken | `/ log(); increment()` |\n\nAll three are optional \u2014 an unlabeled transition is anonymous (completion transition).\n\n```\nA --> B                                      %% anonymous completion\nA --> B : tick                                %% trigger only\nA --> B : [count > 0]                         %% guard only\nA --> B : / clearErrors()                     %% action only\nA --> B : tick [count > 0] / log()            %% all three\nA --> B : tick, tock [enabled] / handle()     %% multi-trigger\n```\n\nLong labels wrap automatically when they exceed the lane width.\n\n---\n\n## 5. Composite states\n\nA composite state contains a nested sub-statechart. The outer state acts as a container with its own initial / final pseudo-states.\n\n```\nstate Playing {\n  [*] --> Buffering\n  Buffering --> Streaming : buffer_full\n  Streaming --> Buffering : underflow\n}\n```\n\nBoth Mermaid syntax (`state X { \u2026 }`) and the Schematex form (`composite X { \u2026 }`) are accepted. Activities can be declared inside the composite block:\n\n```\nstate Playing {\n  entry / startBuffer()\n  exit / stopBuffer()\n  do / decodeFrames()\n\n  [*] --> Buffering\n  Buffering --> Streaming : buffer_full\n  Streaming --> Buffering : underflow\n}\n```\n\nThe renderer draws composites as a styled cluster with title bar + activity compartment.\n\n```\nstateDiagram-v2\n\n[*] --> Stopped\n\nStopped --> Playing : play / loadSource()\nPlaying --> Paused  : pause\nPaused  --> Playing : play\nPlaying --> Stopped : stop / releaseSource()\n\nstate Playing {\n  entry / startBuffer()\n  exit / stopBuffer()\n  do / decodeFrames()\n\n  [*] --> Buffering\n  Buffering --> Streaming : buffer_full\n  Streaming --> Buffering : underflow\n}\n```\n\nCross-boundary transitions (`Outside --> Inside`) are routed automatically \u2014 the Sugiyama layout pulls the source/target through the composite border.\n\n---\n\n## 6. Concurrent regions\n\nInside a composite, the `--` separator (Mermaid) or `---` (Schematex) splits the body into orthogonal regions that run concurrently.\n\n```\nstate Active {\n  [*] --> r1_idle\n  r1_idle --> Connected : connect\n  --\n  [*] --> r2_idle\n  r2_idle --> Working : start\n}\n```\n\nUse `fork` and `join` to spawn / synchronize across regions:\n\n```\nstateDiagram-v2 [direction: LR]\n\n[*] --> F\nstate F <<fork>>\nstate J <<join>>\nF --> A\nF --> B\nA --> J : done_a\nB --> J : done_b\nJ --> [*]\n```\n\n---\n\n## 7. Notes\n\nA short annotation can be attached to either side of any state.\n\n```\nnote right of Checking : Calls /api/verify synchronously.\nnote left of Idle : Anonymous landing state\n```\n\nMulti-line notes use the Mermaid `end note` block form, or the Schematex `{ \u2026 }` form:\n\n```\nnote right of Authenticating\n  Stores the JWT in localStorage\n  on success.\nend note\n\nnote left_of Idle {\n  Anonymous landing state.\n  Returns here on 401.\n}\n```\n\n---\n\n## 8. Self-transitions\n\nA transition `A --> A` renders as a curved arc on the right side of the node.\n\n```\nIdle --> Idle : poll / refresh()\n```\n\nThe label is placed beside the arc, outside the bounding box.\n\n---\n\n## 9. Layout direction\n\nSchematex defaults to **`TB`** (top-to-bottom), matching Mermaid. Override on the header:\n\n```\nstateDiagram-v2\ndirection LR\n\n[*] --> Loading\nLoading --> Ready\n```\n\nOr with the Schematex bracket-attr form:\n\n```\nstate "Order Lifecycle" [direction: TB]\n\n[*] --> Pending\nPending --> Paid\n```\n\n`BT` and `RL` are accepted by the parser but normalized to `TB` and `LR` respectively (the layout engine doesn\'t yet flip the visual order).\n\n---\n\n## 10. Common mistakes\n\n| You wrote | Parser says | Fix |\n|---|---|---|\n| `[*] -> [*]` | Treated as both initial alias and final alias on the same line | Always have at least one named state between `[*]` aliases |\n| `state X <<branch>>` | `branch` is not a stereotype | Use `<<choice>>` (dynamic) or `<<fork>>` / `<<join>>` |\n| `note right of`<br/>`text` | Multi-line note must end with `end note` | Add `end note` on its own line |\n| `composite X` (no braces) | Treated as a bare state declaration | Open the block: `composite X {` |\n| `direction LR` inside composite | Per-region direction not yet supported | Set direction on the header line |\n\n---\n\n## 11. Grammar (EBNF)\n\n```text\ndocument     = header statement*\nheader       = ("stateDiagram-v2" | "stateDiagram" | "state")\n                ( title )? ( "[" attrs "]" )? NEWLINE\nattrs        = attr ("," attr)*\nattr         = "direction:" ("TB" | "LR")\n\nstatement    = comment\n             | direction-stmt              %% direction LR / TB / BT / RL\n             | state-decl\n             | alias-decl                  %% state "Long" as ID\n             | stereotype-decl             %% state ID <<choice|fork|join|end>>\n             | pseudo-decl                 %% initial / final / choice / ... ID\n             | composite-block             %% (state | composite) ID { ... }\n             | label-stmt                  %% ID : description\n             | transition\n             | note-stmt\n             | region-sep                  %% --  or  ---\n\ntransition   = (ID | "[*]") "-->" (ID | "[*]") ( ":" trans-label )? NEWLINE\ntrans-label  = trigger? ( "[" guard "]" )? ( "/" action )?\n\nnote-stmt    = "note" side ID ":" inline-text NEWLINE\n             | "note" side ID NEWLINE  text-line+  ("end note" | "}") NEWLINE\nside         = "left of" | "right of" | "left_of" | "right_of"\n\ncomment      = "%%" any | "#" any | "//" any\n\nID           = [A-Za-z_] [A-Za-z0-9_]*\n```\n\nAuthoritative source: `src/diagrams/state/parser.ts`. If this diverges from the parser, the parser wins \u2014 please open an issue.\n\n---'
+  },
+  "pid": {
+    "title": "P&ID (Piping & Instrumentation Diagram)",
+    "content": '## 1. Your first P&ID\n\nA minimal P&ID has at least one piece of equipment and one process line.\n\n```\npid\n\nequip T-1 : tank_atm\nequip P-1 : pump_centrifugal\nequip V-1 : vessel_v\n\nline L1 from T-1.bottom to P-1.in [size: "2\\\\"", type: "process"]\nline L2 from P-1.out    to V-1.in [size: "2\\\\"", type: "process"]\n```\n\nThree rules cover 80% of usage:\n\n1. Start the document with `pid` (optional title and `[direction: LR]` attrs).\n2. Declare each piece of equipment: `equip  : <type> [tag: "label"]`.\n3. Connect them with `line  from <equip>.<port> to <equip>.<port> [type: "process", size: "4\\""]`.\n\nInstrumentation is added separately with `inst  : <category>` plus indented `measures` / `controls` clauses.\n\n> Comments use `#` at the start of a line.\n\n---\n\n## 2. Equipment\n\nThe `equip` statement declares process equipment. The catalog follows ISO 10628 / ISA-5.1 conventions.\n\n```\nequip T-101 : tank_atm [tag: "Feed Tank"]\nequip P-101 : pump_centrifugal\nequip E-201 : hx_shell_tube [tag: "Overhead Cond"]\nequip T-201 : column_tray [tag: "Stripper"]\n```\n\n### 2.1 Equipment catalog\n\n| Type | Symbol | Purpose |\n|---|---|---|\n| `tank_atm` | Cylinder + dome top | Atmospheric storage tank |\n| `tank_cone_roof` | Cylinder + cone roof | Cone-roof storage tank |\n| `vessel_v` | Vertical capsule | Vertical pressure vessel |\n| `vessel_h` | Horizontal capsule | Horizontal pressure vessel |\n| `sphere` | Filled circle | LPG / ammonia sphere |\n| `column_tray` | Tall capsule + horizontal tray lines | Distillation tray column |\n| `column_packed` | Tall capsule + cross-hatch | Packed absorption column |\n| `hx_shell_tube` | Horizontal capsule + tube bundle | Shell-and-tube heat exchanger |\n| `hx_air_cooled` | Rectangle + fan circle | Air-cooled (fin-fan) cooler |\n| `reboiler` | Capsule + parallel tube lines | Kettle reboiler |\n| `condenser` | Horizontal capsule + tubes | Overhead condenser |\n| `pump_centrifugal` | Circle + right-side triangle outlet | Centrifugal pump |\n| `pump_pd` | Circle + internal gears | Positive-displacement pump |\n| `compressor` | Trapezoid (narrow on right) | Centrifugal compressor |\n| `blower` | Circle + 3-blade fan | Blower / fan |\n| `reactor_cstr` | Vertical capsule + agitator | Stirred tank reactor (CSTR) |\n| `reactor_pfr` | Horizontal capsule + packed bed dots | Plug-flow / fixed-bed reactor |\n| `filter` | Rectangle + diagonal hatch | Filter |\n| `cyclone` | Cylinder + cone bottom | Cyclone separator |\n| `flare` | Tall stack + flame | Flare stack |\n| `cooling_tower` | Hourglass | Induced-draft cooling tower |\n\n### 2.2 Valve catalog\n\nValves are equipment that sit on the piping line. Render in `bowtie` style with type-specific actuator decoration.\n\n| Type | Decoration | Purpose |\n|---|---|---|\n| `valve_gate` | Plain bowtie | Manual on/off (full-port) |\n| `valve_ball` | Bowtie + filled center circle | Manual on/off (quarter-turn) |\n| `valve_globe` | Bowtie + small top circle | Manual flow control |\n| `valve_butterfly` | Bowtie + center vertical line | Quarter-turn throttle |\n| `valve_check` | Bowtie + arc | Non-return check valve |\n| `valve_control` | Bowtie + diaphragm actuator | Pneumatic control valve (paired with FIC) |\n| `valve_psv` | Bowtie + 45\xB0 outlet + spring stack | Pressure safety relief valve |\n\n```\nequip V-101 : valve_control [tag: "V-101 (FC)"]\nequip V-303 : valve_psv     [tag: "V-303 \xB7 150 psig"]\n```\n\n---\n\n## 3. Piping & signal lines\n\nThe `line` statement connects two anchor points (equipment ports or instrument tags).\n\n```\nline L1 from T-101.bottom to P-101.in  [size: "4\\"", service: "water", type: "process"]\nline s1 from FT-101 to FIC-101         [type: "electric"]\nline s2 from FIC-101 to V-101          [type: "pneumatic"]\n```\n\n### 3.1 Anchor syntax\n\nEach end of a line is either:\n- `<equip-id>.<port>` \u2014 port name from \xA72.2 (`in`, `out`, `top`, `bottom`, `feed`, `shell_in`, `tube_out`, `reflux`, etc.)\n- `<equip-id>` \u2014 port omitted; defaults to `in` (target) / `out` (source) per equipment family\n- `<inst-tag>` \u2014 instrument bubble center (signal lines)\n\n### 3.2 Line types (ISA-5.1 \xA75)\n\n| `type:` | Stroke | Use |\n|---|---|---|\n| `process` | Solid, thick | Major process line (default) |\n| `process_minor` | Solid, thin | Auxiliary / utility |\n| `pneumatic` | Solid + diagonal tick marks | Air-actuator signal |\n| `electric` | Long-dash | Electric / 4\u201320 mA signal |\n| `hydraulic` | Long-dash + pause | Hydraulic actuator |\n| `capillary` | Dotted (round caps) | Filled-system temperature |\n| `software` | Short-dash, light | DCS / PLC internal data link |\n| `mechanical` | Mixed dash | Mechanical linkage |\n\n### 3.3 Line tags\n\nThe standard PIP PIC001 tag format is `<size>"-<service>-<sequence>-<spec>`. Pass it via the `tag:` attribute and the renderer places a small white tag rectangle at the line midpoint.\n\n```\nline L1 from T-101.bottom to P-101.in [size: "4\\"", service: "PG", tag: "4\\"-PG-101-A1B"]\n```\n\n---\n\n## 4. Instrumentation (ISA-5.1 \xA74)\n\nThe `inst` statement declares an instrument bubble. The **tag** uses the ISA letter-code convention: first letter is the *measured variable*, subsequent letters are *modifiers* and *function*.\n\n```\ninst FT-101  : field_discrete         %% Flow Transmitter, loop 101\ninst FIC-101 : cr_shared              %% Flow Indicating Controller (DCS)\ninst PSHH-301: cr_plc                 %% Pressure Switch High-High (PLC)\ninst LIC-201 : cr_shared\n  measures D-201\n  controls V-202\n```\n\n### 4.1 Letter codes (first letter)\n\nMost-used: `F` flow \xB7 `L` level \xB7 `P` pressure \xB7 `T` temperature \xB7 `A` analysis \xB7 `S` speed \xB7 `H` hand \xB7 `Y` event/state. Full list in ISA-5.1 Table 1.\n\n### 4.2 Function modifiers\n\n`I` indicator \xB7 `R` recorder \xB7 `C` controller \xB7 `T` transmitter \xB7 `E` element \xB7 `V` valve \xB7 `S` switch \xB7 `A` alarm \xB7 `H`/`L` high/low. Combine into the multi-letter tag: `FIC` = Flow Indicating Controller; `PSHH` = Pressure Switch High-High.\n\n### 4.3 Bubble categories\n\nISA-5.1 distinguishes **location** (where the instrument lives) and **type** (analog vs. shared vs. computer vs. PLC). Schematex implements the four most common combinations:\n\n| Category | Bubble shape | Use |\n|---|---|---|\n| `field_discrete` | Plain circle | Field-mounted analog instrument (FT, PT) |\n| `cr_shared` | Circle + horizontal line + inscribed hexagon | DCS-controlled HMI display |\n| `cr_computer` | Circle + horizontal line + inscribed diamond | Computer function (FY, calculation) |\n| `cr_plc` | Circle + horizontal line + inscribed square | PLC-driven logic |\n\n`field_*` variants omit the horizontal centerline; `local_*` variants use a dashed centerline; `cr_*` variants use a solid centerline indicating "main control panel \u2014 front."\n\n### 4.4 measures / controls\n\nIndented under an `inst` declaration:\n\n| Clause | Effect |\n|---|---|\n| `measures <equip-id>` | Auto-routed dashed-electric signal line from the equipment to the bubble |\n| `controls <equip-id>` | Auto-routed pneumatic signal line from the bubble to the equipment (typically a `valve_control`) |\n\n```\ninst FT-101 : field_discrete\n  measures P-101\ninst FIC-101 : cr_shared\n  controls V-101\n```\n\nThese auto-signals are independent of the explicit `line` statements \u2014 they get rendered with the appropriate signal-line style based on the relation type.\n\n---\n\n## 5. Layout direction\n\nThe default direction is **`LR`** (left-to-right) \u2014 process feed enters on the left, product exits on the right. Override on the header:\n\n```\npid "Distillation Tower" [direction: TB]\n\nequip T-201 : column_tray\n\u2026\n```\n\nThe MVP layout places equipment in declaration order along the primary direction with Manhattan signal-line routing. **Multi-row / parallel-flow layouts and tee junctions are roadmap items** \u2014 see \xA79.\n\n---\n\n## 6. Worked example: Distillation column\n\nA real overhead-condenser loop with reboiler, reflux drum, and instrumentation:\n\n```\npid "Distillation T-201"\n\nequip T-201 : column_tray         [tag: "T-201"]\nequip E-201 : condenser           [tag: "Overhead Cond"]\nequip D-201 : vessel_h            [tag: "Reflux Drum"]\nequip P-201 : pump_centrifugal    [tag: "Reflux Pump"]\nequip E-202 : reboiler            [tag: "Reboiler"]\n\nline L1 from T-201.top    to E-201.shell_in  [size: "8\\\\"", service: "vapor",  type: "process"]\nline L2 from E-201.shell_out to D-201.in    [size: "8\\\\"", type: "process"]\nline L3 from D-201.bottom to P-201.in       [size: "3\\\\"", type: "process"]\nline L4 from P-201.out    to T-201.reflux   [size: "3\\\\"", type: "process"]\nline L5 from T-201.bottom to E-202.in       [size: "6\\\\"", type: "process"]\n\ninst PT-201  : field_discrete\n  measures T-201\ninst LIC-201 : cr_shared\n  measures D-201\ninst TIC-201 : cr_shared\n  measures T-201\n```\n\n---\n\n## 7. Grammar (EBNF)\n\n```text\ndocument    = header statement*\nheader      = "pid" ( title )? ( "[" attrs "]" )? NEWLINE\nattrs       = attr ("," attr)*\nattr        = "direction:" ("LR" | "TB")\n            | "units:" ("imperial" | "metric")\n\nstatement   = comment\n            | equipment-decl\n            | line-decl\n            | instrument-decl\n\nequipment-decl = "equip" ID ":" equip-type ( "[" attr-list "]" )? NEWLINE\nequip-type     = "tank_atm" | "tank_cone_roof"\n               | "vessel_v" | "vessel_h" | "sphere"\n               | "column_tray" | "column_packed"\n               | "hx_shell_tube" | "hx_air_cooled" | "reboiler" | "condenser"\n               | "pump_centrifugal" | "pump_pd"\n               | "compressor" | "blower"\n               | "reactor_cstr" | "reactor_pfr"\n               | "filter" | "cyclone" | "flare" | "cooling_tower"\n               | "valve_gate" | "valve_ball" | "valve_globe" | "valve_butterfly"\n               | "valve_check" | "valve_control" | "valve_psv"\n\nline-decl   = "line" ID "from" anchor "to" anchor ( "[" attr-list "]" )? NEWLINE\nanchor      = ID ( "." port )?\nport        = "in" | "out" | "top" | "bottom" | "left" | "right"\n            | "feed" | "reflux" | "shell_in" | "shell_out"\n            | "tube_in" | "tube_out" | "vapor_out" | "liquid_out"\n            | "bottom_return"\n\ninstrument-decl = "inst" tag ":" inst-category ( "[" attr-list "]" )? NEWLINE\n                  ( indented "measures" anchor NEWLINE )*\n                  ( indented "controls" ID NEWLINE )*\ntag             = letter-code "-" loop-num     %% e.g., "FIC-101"\ninst-category   = "field_discrete" | "field_shared" | "field_computer" | "field_plc"\n                | "cr_discrete"    | "cr_shared"    | "cr_computer"    | "cr_plc"\n                | "local_discrete" | "local_shared"\n\nattr-list   = attr ("," attr)*\nattr        = key ":" value\nkey         = "tag" | "size" | "service" | "type" | "set_pressure"\n            | "actuator" | "fail" | "trays" | \u2026\nvalue       = quoted-string | bare-word\n\nID          = [A-Za-z] [A-Za-z0-9_-]*\n```\n\nAuthoritative source: `src/diagrams/pid/parser.ts`. If this diverges from the parser, the parser wins \u2014 please open an issue.\n\n---'
   }
 };
 
@@ -1108,5 +1135,5 @@ function resolveTypeFromText(text) {
 }
 
 export { DIAGRAM_REGISTRY, getAllDiagramTypes, getDiagramMeta, getExamples, getSyntax, listDiagrams, renderDsl, validateDsl };
-//# sourceMappingURL=chunk-MR5HU5WU.js.map
-//# sourceMappingURL=chunk-MR5HU5WU.js.map
+//# sourceMappingURL=chunk-VLMK7MQK.js.map
+//# sourceMappingURL=chunk-VLMK7MQK.js.map