@litfamily/lithermes 1.0.7 → 1.0.9

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-policy-trace-animated.md

@@ -0,0 +1,69 @@
+# Paired policy-evaluation trace
+
+**Catalog ID:** `policy-trace-animated`<br>
+**Semantic pattern:** paired policy-evaluation traces; visual grammar: flowchart-style rule table.<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Semantic patterns](semantic-patterns.md) · [Motion](motion.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use this view when two otherwise similar requests produce different policy outcomes and the reader needs to see the first rule where their paths diverge. It specializes ordered rule evaluation as two aligned traces. Use Sequence only when actor messages and timing matter; use a regular Flowchart when there is one evaluation path.
+
+## Exclusions
+
+There are exactly two traces, 3–6 shared ordered rules, one first divergence, at most 12 status cells, and one terminal outcome per trace. This is not a general comparison matrix or a decision tree. Do not show a denied request continuing through downstream checks as if they ran.
+
+## Content schema
+
+```yaml
+title: "Where access decisions diverge"
+rules:
+  - { id: identity, label: Identity, detail: "Named principal required" }
+  - { id: data-class, label: Data class, detail: "Sensitive writes denied" }
+  - { id: human-approval, label: Human approval, detail: "Required for writes" }
+traces:
+  - id: read
+    label: Read-only request
+    input_delta: "Read scope"
+    states: [PASS, PASS, SKIPPED]
+    outcome: { status: PERMITTED, detail: "Read allowed" }
+  - id: write
+    label: Sensitive write
+    input_delta: "Write scope"
+    states: [PASS, FAIL, NOT REACHED]
+    outcome: { status: DENIED, detail: "Review required" }
+first_divergence: data-class
+```
+
+Both traces reference the same rule IDs in the same order. Each state is `PASS`, `FAIL`, `SKIPPED`, or `NOT REACHED`; the divergence ID must be the first position at which the two states differ. `SKIPPED` means a rule intentionally did not apply; `NOT REACHED` means evaluation stopped earlier. A failed terminal trace must mark later rules not reached.
+
+## Deterministic layout recipe
+
+Use a wide 1200×660 frame. Reserve the left 38% for ordered rule names and brief conditions, and split the remaining width evenly into trace columns. Build 3–6 rows from top to bottom with a fixed row pitch and identical status-card sizes. Each row carries the same rule label at one y-coordinate and one status cell per trace at that same y. Place the first-divergence bracket/leader across the two cells on the exact divergence row and label it in text. Put outcome cards below the final rule row. Draw all row and connector structure first, then status cards, labels, and the footer key. Set height from row count plus fixed header/outcome/footer zones; do not shrink rows to fit longer text.
+
+## Encoding rules
+
+Every status uses a word plus a redundant mark/shape: PASS, FAIL, SKIPPED, or NOT REACHED. The first divergence receives the single focal accent. Use a dashed neutral border for non-applicable or unreached status; do not equate those states. The denied trace ends at its terminal outcome; no later state is presented as evaluated. Keep persistent rule and trace labels visible in every frame. Motion reveals rows in their existing order; it must not change rule order, state, result, or layout.
+
+## Korean behavior
+
+Translate status labels consistently and keep the English machine status in metadata if a consuming tool requires it. Use short rule names and one-line conditions; keep `PASS`, API names, policy IDs, and HTTP/status codes intact. Provide a static Korean text alternative in rule order. If a translated term needs explanation, put it in the supporting note rather than squeezing the status cell.
+
+## Light, dark, and full variants
+
+All variants share the same two traces, row order, divergence, and statuses. Light/dark swap shared tokens only. The full variant may add a concise decision summary outside the matrix. The default delivered frame shows every rule and both outcomes; optional step mode may focus one row, and its final frame must equal the static complete diagram.
+
+## Accessibility
+
+Add title/description and an ordered text alternative with both input differences, every rule state for both traces, the first divergence, and each outcome. Never encode status or outcome through hue alone. Motion requires keyboard-operable previous/next/play/pause/replay controls, an announced current step, visible focus, and the complete no-motion state described in [Motion](motion.md).
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` for the implemented geometry, contrast, accessibility, and visible-text checks. Run `python3 scripts/verify-type.py --type=policy-trace-animated path/to/diagram.html` to check catalog identity and registered structural rules. Separately verify paired-trace order, first divergence, and outcome consistency against the source. `verify-motion.py` detects unbounded animation and missing reduced-motion source rules; inspect static-first behavior, complete frames, controls, and the final state manually. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Independently ordered traces, missing rules, or a divergence marker on a later mismatch.
+- A green/red dot without its status word and non-color cue.
+- `SKIPPED` used as a synonym for `NOT REACHED`.
+- A denied trace continuing through rules that were never evaluated.
+- Hiding rules or outcomes in an animation-only sequence, or highlighting every row.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-process.md

@@ -0,0 +1,58 @@
+# Process
+
+**Catalog ID:** `process`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Semantic patterns](semantic-patterns.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use Process when order, responsible actor, and the data or tool passed between steps all matter. It is a responsibility-aware workflow: a reader can see who performs each step, where a handoff crosses lanes, and what artifact enters or leaves. Use Swimlane for simpler cross-functional process where payload/tool detail adds no value; use Sequence when timed messages between system actors are the point.
+
+## Exclusions
+
+Do not use this matrix for unowned serial steps, arbitrary many-to-many dependencies, or a static ownership census. It is limited to six lanes and twelve steps. A grid cell with no activity stays empty; no connector should imply a task that the input does not declare.
+
+## Content schema
+
+```yaml
+lanes: [{ key: API, name: [API team] }, { key: OPS, name: [Operations] }]
+steps: [{ number: "1", label: Intake }, { number: "2", label: Validate, focal: true }]
+nodes:
+  - { lane: API, step: 0, title: Receive request, sub: "Request → case", tool: "Portal", chips: { in: null, out: FL } }
+  - { lane: OPS, step: 1, title: Verify access, sub: "Case → approved", tool: "Policy check", chips: { in: FL, out: DB }, focal: true }
+arrows:
+  - { from: { lane: API, step: 0 }, to: { lane: OPS, step: 1 }, style: focal-in }
+```
+
+The schema has 1–6 named lanes, 1–12 ordered steps, explicit occupied cells, and declared arrows. Use short uppercase lane keys and labels, one-line node title, optional short transformation, tool, and input/output artifact codes. First-step inputs and last-step outputs are omitted. Allow one focal step and one focal node; their related handoff is the only accent route. Use arrow styles `normal`, `trigger`, `focal-in`, or `focal-out`.
+
+## Deterministic layout recipe
+
+Use `label_col_w=140`, `step_slot_w=112`, `right_pad=28`, `header_h=36`, and `lane_h=80`. Set canvas width to `140 + 112×step_count + 28`; height to `36 + 80×lane_count + legend_height`, with a 100px legend only when a concern-color row is present, otherwise 80px. Lane `k` starts at `36+80k`; step `j` center is `140+8+112j+50`. Place 100×64 nodes centered in their step slot, with 8px vertical lane inset. Empty cells render nothing. Route cross-lane arrows with one right-angle bend: exit the source right edge, travel in the corridor before the destination, then enter its top or bottom. Same-lane adjacent steps may use a horizontal line. Draw all arrows before all nodes. If routes cross, reorder the steps or split; do not invent extra bends.
+
+## Encoding rules
+
+Use topology to choose line style. A trigger is dashed; ordinary transfer is muted solid; only arrows entering or leaving the single focal node use accent. Node color can signal a concern (security, quality, publication, backup) but is optional, limited to three non-focal elements, and never changes arrow color. Use artifact chips only for known payload types; unknown stays absent. Keep tool/sub-label ink muted even on colored nodes. The legend names only styles actually present.
+
+## Korean behavior
+
+Keep lane keys, units, file formats, and tool names stable in Latin characters. Korean lane names may wrap into two balanced lines; step labels should remain short, and node titles should fit one line or use a two-line title with chips omitted. Do not split a unit from its value or a path/API token at punctuation. Use the shared Korean line-height; widen the canvas or abbreviate before shrinking type.
+
+## Light, dark, and full variants
+
+Light and dark use the same input, viewBox formulas, connector routes, and semantic colors; change only token values and lighten custom hues enough to retain contrast on the dark surface. The full variant places that same grid in an editorial frame and may add a small summary strip. It must not reflow lanes, add process steps, or change arrow semantics.
+
+## Accessibility
+
+Add SVG title and a concise description of the actors, step direction, focal handoff, and any trigger. Provide an ordered text alternative by step, then lane. Distinguish triggers by dash pattern as well as wording; distinguish payload types by text code, not color alone. Keep every connector behind nodes, and ensure node labels stay above minimum readable size.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=process path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the catalog marker against source values and this guide; a matching ID alone does not prove those properties. Review lane/step limits, occupied-cell uniqueness, focal declarations, endpoints, and arrow topology against this guide. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Placeholder boxes in empty lane/step cells or unlabeled lanes.
+- Diagonal connectors, multiple bends, left-side entry, or crossings hidden under nodes.
+- More than one focal step/node, colored arrows, or custom colors on focal elements.
+- Payload chips on nodes whose title already wraps or where the payload is unknown.
+- Twelve-plus steps, seven-plus lanes, or long prose crammed into nodes.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-pyramid.md

@@ -0,0 +1,59 @@
+# Pyramid and funnel
+
+**Catalog ID:** `pyramid`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use a pyramid for a ranked hierarchy where the broad base supports progressively narrower, rarer, or more valuable levels. Use a funnel when a measured audience or quantity drops through successive stages and the narrowing itself communicates attrition. Use Bar when exact comparisons across categories matter more than the taper; use Tree when the relationship branches.
+
+## Exclusions
+
+Do not mix upward pyramid and downward funnel conventions in one figure. A qualitative priority stack must not borrow numeric widths to imply data. A real funnel must not use decorative equal-width layers when observed proportions differ. Do not present arbitrary hierarchical data as if it were a quantity.
+
+## Content schema
+
+```yaml
+orientation: funnel            # pyramid | funnel
+title: "Request conversion"
+unit: "requests"
+layers:                        # 4–6, in visible top-to-bottom order
+  - { id: visit, label: Visit, detail: "10,000", value: 10000 }
+  - { id: signup, label: Sign-up, detail: "4,200 · 42%", value: 4200 }
+  - { id: activate, label: Activation, detail: "1,700 · 17%", value: 1700, focal: true }
+  - { id: retain, label: Retained, detail: "980 · 9.8%", value: 980 }
+```
+
+Each layer has a stable ID, concise label, optional one-line detail, and optional value. A data funnel requires a nonnegative value for every stage, a shared unit and denominator, and a visible count or percentage. A conceptual pyramid may omit values. Mark at most one focal layer.
+
+## Deterministic layout recipe
+
+Use a 1000×560 viewBox and a centered stack from y=80 with equal layer height `h=64` and 8px inter-layer gap. For a qualitative pyramid with `n` layers, interpolate width linearly from 700px at the base to 260px at the apex, then center each trapezoid on x=500. For a funnel, set each trapezoid's width proportional to the declared value on one linear width scale (`width_i = max_width × value_i / max_value`), retaining a small minimum only if it is labeled as a visual floor and does not alter ranking; default is no floor. Pyramid order is broad base to narrow apex bottom-up; funnel order is largest first at the top. Put label and value at each trapezoid's horizontal center; place optional drop-off notes in a consistent side column. Extend the viewBox if labels exceed the safe area rather than squeezing the stack.
+
+## Encoding rules
+
+Width represents magnitude only in a measured funnel and is proportional to its value. For conceptual hierarchies, the taper is a convention, not a numerical scale; say so in the subtitle or alternative text if ambiguity is possible. Use one neutral treatment across layers, with one accent layer at most: the apex in a pyramid, the conversion bottleneck in a funnel, or one user-selected focal stage. Keep layer height equal. An optional axis arrow may say “rarer” or “drop-off” but cannot replace labels.
+
+## Korean behavior
+
+Use short Korean nouns for stages and concise numeric notation with the shared Korean number and unit format. Keep `%`, count units, and the value together. Labels may wrap to two lines inside wide layers; narrow apex layers get a shorter label. Keep Korean line-height consistent and put explanatory prose outside the trapezoid.
+
+## Light, dark, and full variants
+
+Light and dark retain the same widths, order, labels, and accent target. Change only shared tokens; check each outlined trapezoid against its paper background. The full variant may add a restrained title and one or two summary notes beside the stack, while preserving all layer geometry and data.
+
+## Accessibility
+
+Give the SVG an accessible title and description that state orientation and whether widths are quantitative. Provide a text list in stage order containing each label, value, unit, and denominator. Use labels and numeric text so no comparison depends on color. Keep stroke boundaries visible between neighboring layers and ensure text does not cross polygon edges.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=pyramid path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the catalog marker; manually reconcile declared values and rendered widths for quantitative funnels against source values and this guide; a matching ID alone does not prove those properties. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Seven or more layers, unequal decorative layer heights, or layers too small to label.
+- Quantitative funnel widths that are equal, reversed, or unrelated to declared values.
+- A data value hidden only in a source note, or a percentage without its denominator.
+- Multiple accent layers, gradients that imply a second scale, shadows, or separate rainbow colors.
+- Using a pyramid for unrelated categories or using a funnel for a hierarchy without attrition.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-quadrant-consultant.md

@@ -0,0 +1,60 @@
+# Quadrant consultant: scenario matrix
+
+**Catalog ID:** `quadrant-consultant`<br>
+**Parent grammar:** [Quadrant](type-quadrant.md).<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use this 2×2 scenario layout for four named futures, archetypes, or strategic options defined by two independent drivers. The cell is the conclusion; text inside each cell explains the scenario. Select standard `quadrant` when an item's exact point location within a cell carries information. This variant has no point cloud and does not imply a score.
+
+## Exclusions
+
+Exactly two drivers and four cells. Do not use it for prioritization, density, measured coordinates, three-by-three grids, or a matrix where points cluster inside cells. It is not a replacement for a risk heatmap or a ranking table.
+
+## Content schema
+
+```yaml
+title: "Four operating futures"
+x_axis: { low: Local, high: Global }
+y_axis: { low: Stable, high: Volatile }
+scenarios:
+  - { id: "01", x: low, y: high, name: "Rapid fragmentation", description: "Regional platforms set the rules.", focal: true }
+  - { id: "02", x: high, y: high, name: "Open competition", description: "Shared standards coexist with volatility." }
+  - { id: "03", x: low, y: low, name: "Steady federation", description: "Local systems change slowly." }
+  - { id: "04", x: high, y: low, name: "Managed scale", description: "A few stable global platforms dominate." }
+```
+
+Every cell needs a distinct scenario name and a 1–3 line description. Each scenario records its high/low combination explicitly; do not calculate an interior position. Exactly one focal scenario receives accent treatment. Axis names and cell tags must use the same driver terms.
+
+## Deterministic layout recipe
+
+Use a 1000×620 canvas. Place four equal 280×180 cells in a 2×2 arrangement around an open 48px central axis gap; center their shared axes at the canvas midpoint. Extend both axes beyond the outer cell edges by 24–36px, with arrowheads at both ends. Put the single-word endpoint labels beyond the arrow tips with fixed offsets: top/bottom centered, left right-aligned, right left-aligned. Inside each cell, place a small numbered corner tag, a left-aligned scenario title, then a description constrained to three lines. Cell text starts from the same inset in all four quadrants. Add the standard bottom legend rule and two neutral/accent swatches. If localized text does not fit, grow the canvas or abbreviate; do not resize one cell.
+
+## Encoding rules
+
+Cells encode only the two high/low combinations. One scenario may use a light accent tint, accent border, and accent corner tag; the other three use a neutral treatment. No dot position, cell area, opacity ramp, or fill color represents a quantity. The label tag states the matching x/y combination so readers can verify axis polarity without inferring it from color.
+
+## Korean behavior
+
+Keep axis endpoints to concise Korean terms whose polarity is unambiguous. Cell titles may wrap once; descriptions use at most three balanced lines and the shared Korean line-height. Keep the scenario number adjacent to its name and preserve any Latin acronym as a whole. Localize all four cells together; do not leave one quadrant in a different language unless it is a proper name.
+
+## Light, dark, and full variants
+
+Keep cells, axis directions, labels, scenario mapping, and focal choice identical across skins. The full variant may add an editorial title and a short “decision to watch” note outside the matrix. Do not convert the layout into a branded whiteboard: retain the shared paper, rule, and typography system.
+
+## Accessibility
+
+The SVG description identifies both drivers and the four high/low combinations. Provide a text alternative listing cells in reading order (top-left, top-right, bottom-left, bottom-right), each with its driver combination, title, and description. State the focal scenario in words. Arrow directions and printed endpoint labels must survive grayscale output.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=quadrant-consultant path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the catalog marker; manually check the four cell assignments and focal scenario against source values and this guide; a matching ID alone does not prove those properties. Cell narratives are not quantitative points. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Empty “Scenario 1–4” placeholders in a finished diagram.
+- Unequal cells, dot clouds, or invented numerical placement within cells.
+- One-way axes, missing endpoint labels, arrow glyphs in the labels, or tags inconsistent with the axes.
+- Multiple focal cells, bold axis labels, extra colors, or a 3×3 layout.
+- Long consulting prose that forces tiny type or abandons the common visual system.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-quadrant.md

@@ -0,0 +1,57 @@
+# Quadrant
+
+**Catalog ID:** `quadrant`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md) · [Consultant scenario variant](type-quadrant-consultant.md)
+
+## Purpose and selection
+
+Use Quadrant to position a small set of named items against two independent, meaningful axes: prioritization, portfolio review, or product positioning. Position inside the cells matters. If the brief wants four named futures with a short narrative in each cell and no within-cell position, select the separate `quadrant-consultant` catalog entry. Use a table if precise ranks or scores need comparison.
+
+## Exclusions
+
+Do not use the quadrant for more than two dimensions, time series, large point clouds, or categories with no interpretable axes. Items exactly on an axis have ambiguous membership; ask for a placement rule or keep them out of the chart. The standard grammar is capped at twelve points.
+
+## Content schema
+
+```yaml
+title: "Work to do first"
+x_axis: { label: Impact, low: Limited, high: Broad, min: 0, max: 10 }
+y_axis: { label: Ease, low: Difficult, high: Easy, min: 0, max: 10 }
+items:
+  - { id: auth, label: Access review, x: 8, y: 8, focal: true }
+  - { id: cache, label: Cache cleanup, x: 5, y: 6 }
+```
+
+Each item carries a stable ID, short label, and x/y values on the declared axes. Normalize both coordinates to the plot range; keep raw values available for visible labels only when exactness matters. At most one item is focal. Axis endpoint terms explain direction; quadrant captions are optional and short.
+
+## Deterministic layout recipe
+
+Use a 1000×560 viewBox with a plot rectangle x=160..840, y=104..424. Put the cross at the midpoint `(500,264)`. Map values linearly: `px=160+680×(x−xmin)/(xmax−xmin)` and `py=424−320×(y−ymin)/(ymax−ymin)`. Draw the two hairline axes through the center, leaving arrow tips and one-word axis labels outside the plot margins. Place each point at its mapped coordinate; keep point marks small and labels 8–10px away. Use a fixed label-placement order (above-right, above-left, below-right, below-left), then choose the first candidate that clears the point, axis, and prior labels. If none fits, reduce the number of items or split the chart; never move the point. Keep labels away from axis lines.
+
+## Encoding rules
+
+Position is the data. Use a small neutral circle for ordinary items and one accent focal point. Do not fill the four cells with different colors. Name both axes, their direction, and their units or scales. Optional quadrant captions sit in the corners and remain subordinate to item labels. If scores are illustrative, say so plainly; do not use approximate placement as a claim of measurement.
+
+## Korean behavior
+
+Keep axis names and endpoint labels short, one line where possible. Use Korean directional terms with clear low/high meaning; do not rely on arrows or color to explain polarity. Korean item names may wrap to two lines. Keep item labels within the plot and avoid breaking mixed Hangul/Latin identifiers or numeric units.
+
+## Light, dark, and full variants
+
+The three variants use the same axis ranges, point positions, label placements, and focal item. Light/dark changes are token-only. The full variant may add a compact interpretation card or a few editorial callouts outside the plotting area; no card may restate every point, and the 2×2 plot itself must remain primary.
+
+## Accessibility
+
+Include title and description naming both axes and the key focal item. Provide a reading-order list of item labels and values. A screen reader must hear each item's two axis values; the focal state must be stated in text. Ensure axes and point outlines meet non-text contrast, with labels readable independently of the mark color.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=quadrant path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the catalog marker; manually compare point positions with declared axis bounds and labels against source values and this guide; a matching ID alone does not prove those properties. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Four differently colored cell fills, unlabeled axes, or labels placed over the axis cross.
+- Points on either axis without an explicit placement policy.
+- More than twelve items or moving a point to make its label fit.
+- Axis glyphs, vague labels such as “good/bad,” or unsupported score precision.
+- Using this point plot for four scenarios that belong in the consultant variant.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-queue-animated.md

@@ -0,0 +1,63 @@
+# Fan-in queue and bottleneck
+
+**Catalog ID:** `queue-animated`<br>
+**Semantic pattern:** fan-in queue / bottleneck; visual grammar: data flow.<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Semantic patterns](semantic-patterns.md) · [Motion](motion.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use this pattern when several sources compete for one limited service point and arrival rate, queue depth, capacity, waiting, or backpressure explains the outcome. It combines a static capacity diagram with an optional step reveal. Use Process when successive service stages dominate and source contention is secondary; use Sankey when conserved quantity splitting/merging is the central claim.
+
+## Exclusions
+
+Budget: at most five sources, five visible queue slots, one bottleneck, two outcomes, and nine primary nodes. Aggregate extra sources into a named cohort. The queue is ordered FIFO unless the input explicitly says otherwise. Animation may reveal events but may not reorder items. Do not animate purely decorative traffic or imply capacity only through box size.
+
+## Content schema
+
+```yaml
+title: "Ingress under a burst"
+producers:
+  - { id: web, label: Web client, rate: 4, unit: "requests/s", pattern: steady }
+  - { id: webhook, label: Payment hook, rate: 8, unit: "requests/s", pattern: burst }
+queue: { label: Ingress buffer, discipline: FIFO, capacity: 5, unit: slots }
+slots: [{ id: q1, item: "GET /orders", step: 1 }, { id: q2, item: "POST /auth", step: 1 }, { id: q3, item: "POST /payment", step: 2 }, { id: q4, item: "ERP batch A", step: 2 }, { id: q5, item: "ERP batch B", step: 2 }]
+static_occupancy: 5
+overflow_rate: { value: 4, unit: "requests/s" }
+service: { label: Worker, capacity: 8, unit: "requests/s" }
+outcomes: [{ id: admitted, label: Admitted }, { id: shed, label: "429 · backpressure" }]
+steps: ["arrivals", "queue full", "backpressure", "service", "equilibrium"]
+```
+
+Include rates with units, queue capacity and discipline, a constrained service rate, each outcome, and the static queue state. Each step must be derived from the scenario; all slot states and occupancy counts must agree. Keep status words such as `FULL` or `SHED` alongside the numeric count.
+
+## Deterministic layout recipe
+
+Use a wide 1160×640 canvas. Reserve a left column for distinct producer cards, a central column for a bounded queue with one visible slot per unit of capacity, and a right column for the constrained worker and downstream destination. Place an overflow/backpressure sink above or below the worker, outside the queue's main route. Producers enter at separate fixed y coordinates; route each ingress line to its assigned slot so fan-in remains traceable. Use a single queue-depth badge aligned to the full slot stack. Add an equilibrium summary below the queue and a compact legend along the footer. Step groups may add arrivals, fill slots, activate the overflow route, and show service, but every frame uses the same positions and item order. Keep a complete final frame as the default export.
+
+## Encoding rules
+
+Label every flow rate and capacity with units. Distinguish admitted traffic, overload traffic, and rejected/deferred output using line style and text as well as color. The queue's count is `occupied/capacity`, not a decorative badge. Show a visible sink for rejected work and a path for admitted work. Use one accent to direct attention to the bottleneck or overload path; do not color every producer. Static fallback shows the representative queue state, capacity, service rate, and both outcomes at once.
+
+## Korean behavior
+
+Keep API paths, HTTP codes, rate units, and queue policies intact. Korean captions should use compact verbs and nouns, with the count and unit kept together (for example, `5/5칸`, `초당 8건`). Avoid line breaks inside identifiers. The accessible summary must explain steady versus burst arrivals in Korean and preserve item order.
+
+## Light, dark, and full variants
+
+Light/dark retain identical sources, rates, queue occupancy, routes, step sequence, and final frame. Change only shared tokens. The full variant may add one editorial frame and a short operational takeaway outside the queue drawing. Static, reduced-motion, and print/export views show all essential routes and the final queue state; no conclusion may depend on animation.
+
+## Accessibility
+
+The SVG description states source count, queue discipline/capacity, service limit, and admitted/rejected outcomes. Include a linear reading list of producers, ordered slots, service rate, and outcomes. Step controls must be keyboard-accessible and announce the current event. Status uses text plus shape/border; color alone never means full, blocked, or overloaded. Follow the full keyboard, reduced-motion, focus, and no-JS contract in [Motion](motion.md).
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=queue-animated path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the registered fan-in contract: producer/service units, queue occupancy/capacity, outcomes, and route semantics against source values and this guide; a matching ID alone does not prove those properties. Run `python3 scripts/verify-motion.py path/to/diagram.html` to detect unbounded animation and missing reduced-motion source rules. Inspect the static state, frame order, and controls manually. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Equal-width pipeline that hides fan-in or arrows merged before their sources can be traced.
+- Queue occupancy inferred from box size, a count above capacity, or capacity without units.
+- Decorative pile-up, changing FIFO order, or a blocked path that rejoins the admitted route.
+- More than five sources/slots, one or more hidden outcomes, or red as the only overload cue.
+- An animation whose static frame does not explain why work waits.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-radar.md

@@ -0,0 +1,57 @@
+# Radar and spider chart
+
+**Catalog ID:** `radar`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use Radar to compare 3–5 entities across 3–5 quantitative criteria on one shared, normalized scale. It is useful when several dimensions form a recognizable profile. Use a table or grouped bar chart for two entities, many criteria, or exact values that readers need to compare; use Polar for one series across cyclic categories.
+
+## Exclusions
+
+All axes must be meaningful, measurable, and comparable after explicit normalization. Do not mix units without a declared transformation, use more than five axes or series, begin at a nonzero baseline, or treat the polygon area as an extra value. Two-series charts usually have clearer alternatives. A measured scientific dataset belongs in the scientific-visualization workflow when that is the requested task.
+
+## Content schema
+
+```yaml
+title: "Storage options"
+scale: { min: 0, max: 10 }
+axes: [Latency, Durability, Cost, Operations, Portability]   # 3–5
+series:
+  - { id: local, label: Local, values: [8, 6, 7, 5, 8] }
+  - { id: managed, label: Managed, values: [7, 9, 6, 8, 7], focal: true }
+  - { id: community, label: Community, values: [6, 7, 7, 6, 6] }
+```
+
+Every series has exactly one finite value per axis within the shared range. Normalize source measures before drawing and record the method/meaning of the common scale. Keep axis order fixed across every series and skin. At most one series is focal.
+
+## Deterministic layout recipe
+
+Use a 1000×560 viewBox, center `(500,240)`, and outer radius `R=160`. For axis `i` of `N`, set `angle=−π/2+2πi/N` and outer vertex `(cx+R cos(angle), cy+R sin(angle))`. Draw five closed polygon rings at fractions 0.2, 0.4, 0.6, 0.8, 1.0; spokes connect center to each outer vertex. For value `v` on scale maximum `S`, its vertex is `center+(v/S)×(outer_vertex−center)`. Round optional serialized coordinates consistently, but do not alter values. Place one-word axis labels 16px beyond their outer vertex. Put numeric scale ticks along the top axis only. Paint non-focal polygons in stable input order from smallest area to largest, then focal polygon and focal vertices, then legend. Preserve the same series order in the legend.
+
+## Encoding rules
+
+The normalized value along each spoke carries the comparison; polygon fill is only a light translucent aid. Use an editorial series palette with one accent focal series, not one arbitrary hue per item. Show focal vertex markers only on the focal series. Label series by name in the legend; label axis criteria directly. Do not truncate the zero baseline. State the normalization so a “7” has one interpretation on every spoke.
+
+## Korean behavior
+
+Shorten axis names to one word in Korean when possible. Keep scores and denominators explicit, e.g. `7/10`, and state whether high means more or better. Preserve identical axis order in the Korean version. A two-line axis label is allowed only when placed outside the plot and not overlapping its neighbor; otherwise use an explanatory key.
+
+## Light, dark, and full variants
+
+Light/dark preserve data, geometry, series order, normalization, and focus. Only shared tokens and contrast-safe palette variants change. The full variant may add a short summary for the focal option and brief comparison cards; those summaries must not introduce values absent from the chart.
+
+## Accessibility
+
+Include SVG title/description naming the entities, criteria, scale, normalization, and focal series. Provide a table-like text alternative with one row per entity and one value per criterion. Ensure patterns and labels distinguish series in grayscale; do not make polygon hue the sole identity cue. Keep grid and spokes subtle but perceptible.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=radar path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the catalog marker against source values and this guide; a matching ID alone does not prove those properties. No specialized radar proof is registered; manually compare the declared values, axis order, and coordinates across variants. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- More than five series or axes, two-series radar, or a mixed scale with no normalization.
+- A truncated inner ring, non-quantitative axes, or a polygon area presented as a metric.
+- Dots on every series, a rainbow, multiple focal series, or unlabeled polygons.
+- Axis labels in mono type, text over the grid, or different axis order between skins.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-ridgeline.md

@@ -0,0 +1,63 @@
+# Ridgeline
+
+**Catalog ID:** `ridgeline`<br>
+**Parent family:** distribution variant of Line; select `ridgeline` directly when each row is a distribution, not a value at each time.<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use Ridgeline to compare several distributions on a shared horizontal scale when shape, spread, or multimodality matters more than a summary percentile. A ridge represents one distribution. Use a histogram for one distribution, small multiples for two, Line for a time series, or a table of percentiles when shapes are alike and a compact exact summary is clearer.
+
+## Exclusions
+
+Use 3–12 distributions, 8–40 shared bins, one unit and x-domain, and one shared amplitude. The grammar does not show sample size or total volume: each distribution is normalized to its own count before shared scaling, so ridge height is concentration/shape, not traffic. Different units or x-ranges cannot share this layout. Avoid smoothing unless the method and true bin vertices are explicit; default is unsmoothed straight segments.
+
+## Content schema
+
+```yaml
+title: "Request latency distributions"
+unit: "ms"
+x_domain: [0, 500]
+bins: [0, 40, 80, 120, 160, 200, 240, 280, 320, 360, 400, 440, 500]
+normalization: probability-density-per-series
+amplitude: 1.0                  # one shared peak-to-pixel factor
+series:
+  - { id: checkout, label: Checkout, counts: [0, 1, 6, 17, 21, 14, 8, 6, 7, 9, 7, 4, 0], focal: true }
+  - { id: search, label: Search, counts: [0, 2, 7, 13, 18, 15, 11, 8, 5, 3, 2, 1, 0] }
+```
+
+Every ridge has the same bin count, x-domain, and known bin values, with zero at both ends so its path returns to baseline. Record the normalization and shared amplitude. At most one ridge is focal. If absolute population size matters, add an explicit sample-size label or choose a chart that encodes volume.
+
+## Deterministic layout recipe
+
+Use a 1000×500 viewBox. Shared x-run is 320–680; map each bin linearly across this span. For `n` ridges, use baselines at `y=152+56i` for five rows; when `n` differs, center the fixed 56px-pitch stack vertically. Convert normalized density to height with the same amplitude for every row. Draw each ridge as a closed polygon: start at the baseline, draw straight segments through each bin point, return to the baseline, close. Do not use splines. Put the series name left of its baseline and its nonzero x-range right of it, aligned to that row. Put bin labels below the stack and one vertical amplitude caption at the left. Draw baselines, then neutral ridges from top to bottom, then the focal ridge and labels. No gridlines.
+
+## Encoding rules
+
+X-position is the shared value domain; vertical height is normalized density. State both in the source note/description, and state that total volume is not encoded. Use one accent ridge and a restrained ink-opacity ramp for others, with fixed stroke weights and low-opacity fills. Keep range labels bound to the bins they summarize. A common amplitude is essential: do not normalize ridge heights independently to make every profile equally tall. Any overlap is deliberate and limited to the next row; peaks must not obscure two rows above.
+
+Bind each ridge path with a unique `data-ridge`, its zero baseline in `data-baseline`, and its ordered comma-separated bins in `data-bins`. Draw one baseline rule per ridge using the same `data-ridge` and `data-role="baseline"`; bind name/range labels to that ID with `data-role="name"` or `data-role="range"`. Each bin tick carries `data-tick` (index) and `data-bin` (value). The checker reads raw geometry, so do not move a path, label, or ancestor with transforms or CSS geometry.
+
+## Korean behavior
+
+Keep every ridge name on its baseline and x-range in the same unit. Use Korean service/cohort labels as concise nouns. Format the shared x-axis units once, and keep bin values and units together. If Korean names wrap, reserve a wider left gutter for all rows; never alter ridge centers or amplitude to make room.
+
+## Light, dark, and full variants
+
+Use identical distributions, shared domain, amplitude, baseline pitch, and accent target in every variant. Light/dark change only shared tokens; use skin-neutral ramp wording such as “strongest tone,” not “darkest.” The full variant may add a small editorial frame or summary cards with already-declared statistics; it may not imply volume from ridge height.
+
+## Accessibility
+
+Describe the measure, unit, domain, normalization, shared amplitude, and meaning of vertical height. Provide a text table with each series name, nonzero range, and any separately declared sample size. Do not rely on opacity or accent to identify rows. Keep outlines contrast-visible and provide a nonvisual statement that overlapping outlines are separate distributions.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=ridgeline path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify every bin vertex against one shared domain/amplitude, validate baselines/pitch, range labels, endpoint closure, series count, and variant parity against source values and this guide; a matching ID alone does not prove those properties. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Private amplitude or baseline for one ridge, or reading volume from ridge height.
+- Different domains, units, or bin centers across rows.
+- A path that starts/ends above baseline, clips mass, or invents a peak with smoothing.
+- Too-tight pitch that hides the row above, one color per series, or a “darker is faster” key.
+- One or two ridges, more than twelve, or ranges omitted from a shape-only comparison.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-sankey.md

@@ -0,0 +1,68 @@
+# Sankey and flow quantity
+
+**Catalog ID:** `sankey`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use Sankey when a quantity splits or merges across stages and ribbon width is the main message: cost allocation, CI time, staffing, or volume movement. Use Pyramid/Funnel for a one-way drop-off without branching; Process for ordered steps without amount encoding. If exact comparisons matter more than flow, use a table or bar chart.
+
+## Exclusions
+
+Exactly three left-to-right stage columns, at most eight nodes and twelve ribbons. Quantities are nonnegative and must conserve at each intermediate node and between columns. A path cannot branch into unstated amounts. No arrowheads: direction is carried by ordered columns. Merge tiny flows into a named “Other” only if the aggregation preserves the total and is explained.
+
+## Content schema
+
+```yaml
+title: "Build minutes by outcome"
+unit: "minutes"
+scale: { px_per_unit: 0.02 }
+stages: [Budget, Test stage, Outcome]
+nodes:
+  - { id: budget, stage: 0, label: CI total, value: 12000 }
+  - { id: tests, stage: 1, label: Tests, value: 7000 }
+  - { id: build, stage: 1, label: Build, value: 5000 }
+  - { id: passed, stage: 2, label: Passed, value: 10000 }
+  - { id: failed, stage: 2, label: Failed, value: 2000 }
+flows:
+  - { id: budget-tests, from: budget, to: tests, value: 7000, focal_path: false }
+  - { id: budget-build, from: budget, to: build, value: 5000, focal_path: false }
+  - { id: tests-passed, from: tests, to: passed, value: 6000, focal_path: false }
+  - { id: tests-failed, from: tests, to: failed, value: 1000, focal_path: false }
+  - { id: build-passed, from: build, to: passed, value: 4000, focal_path: false }
+  - { id: build-failed, from: build, to: failed, value: 1000, focal_path: true }
+```
+
+List exactly three stages, unique nodes in a stage, and explicit source/target/value per flow. Use one unit and one pixels-per-unit constant. A middle node's incoming and outgoing sums equal its declared value; the first and final columns balance to the same overall total. Mark one editorial path at most.
+
+## Deterministic layout recipe
+
+Set one `k` px-per-unit scale for every node and flow. Convert quantities with `height=k×value`, rounded to the nearest 4px for grid alignment; reconcile rounding at each node so its attached ribbons still sum exactly to its rendered height and limit any stated-value discrepancy to one 4px step. Use identical total stack height for each stage. Give each node a 12px bar; stack nodes vertically in a stable input order within each column. Assign each flow a distinct cumulative top/bottom offset interval inside its source and target node. Draw ribbons as one closed cubic path with both control points at the horizontal midpoint between columns, giving a horizontal tangent at both bars. Place column-one labels outside left, column-two labels centered vertically in the clear gutter, and column-three labels outside right. Add headers above and a legend/footer below. Reorder nodes to reduce crossings before changing geometry.
+
+## Encoding rules
+
+Ribbon thickness and node height both encode quantity. Use one muted ribbon treatment for ordinary paths and accent for one focal path; never a distinct hue per flow. No arrowheads, no hidden offsets, and no overlap between ribbons attached to the same bar. Every quantity is printed with its unit and reconciles to the geometry. Keep the smallest visible ribbon at least 4px; aggregate a smaller one only with a documented total.
+
+## Korean behavior
+
+Keep amounts, units, and percentages bound together using one Korean number format. Stage headings may use short Korean nouns; node names should fit a single line where possible. Put unit in the title/subtitle once and retain units beside values when ambiguity remains. Do not wrap a number away from its unit or shorten a label so it changes the underlying category.
+
+## Light, dark, and full variants
+
+All skins use the same nodes, values, scale, ribbon offsets, order, and focal path. Switch shared paper/ink tokens only. A full variant can add concise summary cards, but each card must repeat a declared quantity exactly and must not recalculate the diagram on a different scale.
+
+## Accessibility
+
+Describe the unit, stage order, total, and focal path in the SVG description. Provide a text table of node totals and flow values, with source/target names. Ensure direction is understandable from stage names and text; distinguish focal flow by label as well as accent. Do not place text over ribbons.
+
+## Verifier gates
+
+Run `python3 scripts/verify-diagram.py --canvas path/to/diagram.html` to check implemented SVG geometry, overlap, contrast, accessibility, and visible-text rules. Review theme or profile polarity, data correctness, and other unreported properties manually. Run `python3 scripts/verify-type.py --type=sankey path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify stage/node/flow budgets, conservation, one scale, ribbon thickness, attachment offsets/tangents, crossings, and variant parity against source values and this guide; a matching ID alone does not prove those properties. See [Verifier guide](verifier-guide.md). See that the gallery wrapper’s `data-type` value matches this exact Catalog ID; a missing or mismatched marker is not a passing type check.
+
+## Anti-patterns
+
+- Ribbon meeting a bar at a slant or a control point that collapses at the target.
+- Intermediate labels pinned to a ribbon edge, or an opaque mask that cuts a hole in a band.
+- Flow totals that do not balance, different scales by column, or unexplained rounding.
+- Ribbons under 4px, repeated attach intervals, or tangled crossings.
+- Rainbow flows, arrows on ribbons, or a Sankey used for a simple funnel/process.