@litfamily/lithermes 1.0.7 → 1.0.9

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

@@ -0,0 +1,54 @@
+# Line chart
+
+Catalog ID: line
+
+## Purpose and selection
+
+Use the line entry when ordered time or index points form a continuous trend and the story concerns direction, pace, or turning points. It can show one or a small number of comparable series. This canonical type is for editorial product and operational diagrams; measured scientific data and statistical analysis belong to the dedicated scientific-visualization workflow.
+
+## Exclusions
+
+Use a bar chart for discrete category comparison, a slopegraph for exactly two states with direct endpoint comparisons, a bump chart for rank movement across snapshots, and a ridgeline for distributions rather than one observation per period. Do not join gaps in the data. Avoid more than five series or twelve points in the base chart.
+
+## Content schema
+
+Provide ordered x values and labels; one unit-consistent y value per series and x; declared source, period, and missing-data policy; a shared numeric domain with sensible tick labels; one optional focal series with editorial rationale; and a legend or direct labels. A value is numeric metadata and visible text must agree with it. For product-level summaries, say whether values are actual, sampled, or illustrative.
+
+## Deterministic layout recipe
+
+Use a 1000 × 500 viewBox. Plot bounds are x=80..960 and y=40..420, with axis captions and legend below. Use 4–12 evenly spaced x positions, computed across plot width; use 4–6 horizontal grid lines from the declared y domain. Map y to position with one linear scale for all series. Use a polyline with straight segments; focal stroke width is 1.8px and other lines are 1.2px. Show point dots only on the focal series when several lines are present. If the chart has one short series, dots at all observations may be used. Reserve the lower key band for one sample per series and one source line. Keep design constants on a 4px grid; do not snap data-derived point coordinates.
+
+## Encoding rules
+
+The common plot is allowed a restrained series palette because color helps track a line through many points; use palette order without skipping and reserve the accent for one focal series. Pair hue with direct names, stroke-weight distinction, and optionally dash patterns. Do not use smooth curves to imply unobserved values. Include zero when absolute magnitude comparison requires it; otherwise state the chosen domain and reason. A gap remains a gap. A title makes the takeaway explicit while the axes retain units and scale.
+
+## Korean behavior
+
+Use Korean period labels when the audience is Korean, with the same interval and ordering as the source. Format dates, values, percentages, and units consistently with the shared Korean guide. Use Pretendard for axis and series names; use mono for tick values and short technical units. Do not rotate Hangul labels. Widen margins or abbreviate at phrase boundaries rather than reducing text below the output preset.
+
+## Light, dark, and full variants
+
+Light and dark skins use the same domain, positions, line order, gaps, labels, and data. Recheck line contrast and ensure the series palette remains distinct on both papers. Full editorial may add a title, one takeaway sentence, source/date, and one explanatory annotation outside the plot. It cannot change the plotted data or use decorative motion. See the companion slopegraph, ridgeline, streamgraph, and bump guides for their own grammars.
+
+## Accessibility
+
+Provide SVG title and description with measure, period, units, domain, series count, and missing-data policy. Use direct series labels or a readable key; do not make color the only series identifier. Include the data as a text table when precise values matter. Keep grid lines subordinate but visible and all data marks distinguishable in grayscale.
+
+## 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=line path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify bound values, x ordering, shared domain, gaps, point count, and printed labels against source values and this guide; a matching ID alone does not prove those properties. Inspect the rendered chart for crossings, label collisions, and false continuity. Run humanizer checks on title, axis captions, annotation, and key.
+
+## Anti-patterns
+
+- Spline smoothing through sparse observations.
+- Connecting across a missing interval.
+- Inconsistent or undisclosed scales across series.
+- More than five series without splitting into panels.
+- Hiding an important baseline or using a cropped y-axis without explanation.
+- Dots on every point of every dense line.
+- Using a scientific-data plot here when its uncertainty and analysis belong to the scientific-visualization workflow.
+- Changing plotted coordinates to give one label more room.
+
+## Related references
+
+[Style guide](style-guide.md) · [Output spec](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md) · [Slopegraph](type-slopegraph.md) · [Ridgeline](type-ridgeline.md) · [Streamgraph](type-streamgraph.md) · [Bump chart](type-bump.md)

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

@@ -0,0 +1,53 @@
+# Loop in terminal frame
+
+Catalog ID: loop-terminal
+
+## Purpose and selection
+
+Choose this variant when a loop is being presented as a command-line or developer-tool concept and a restrained terminal window helps identify that context. The diagram inside remains the canonical Loop: an actual clockwise cycle, one shared-state hub, and optional dashed write-backs. The terminal chrome is a frame around the same diagram, not a new diagram grammar.
+
+## Exclusions
+
+Use plain [Loop](type-loop.md) for reports, slides, or audiences that do not benefit from the terminal metaphor. Do not use this frame to imply that a command was run, a log was captured, or output is executable. Use the terminal primitive for actual short command/output excerpts; do not replace a technical diagram with a fake shell transcript.
+
+## Content schema
+
+Accept the Loop schema unchanged: five to eight ordered stations, exactly one hub, a true closing transition, optional station-to-hub write-backs, and no more than one focal station. Add a short window title or filename-like context string and an optional single prompt line that describes the diagram concept. The prompt is decorative framing text, never a command to copy or execute.
+
+## Deterministic layout recipe
+
+Use a dark terminal frame with a 12px outer corner radius, 1px border, and a narrow title bar. Place three small neutral window marks at the leading edge; they are decorative. Center a compact terminal-title string in the header. In the content area, put one subdued prompt line, then the diagram title, then the unchanged 1040 × 680 Loop SVG. At a 1200px maximum frame width, preserve the SVG's 900px minimum width and give the SVG container local horizontal scrolling on narrow screens. Keep the title bar, prompt, heading, and diagram in fixed vertical order. The diagram geometry is produced by [Loop](type-loop.md); never rescale its labels independently.
+
+## Encoding rules
+
+Use the shared dark semantic tokens rather than a neon terminal palette. The shell frame uses restrained borders; the diagram keeps the Loop's neutral ring, dashed write-backs, one hub, and optional one focal station. Use a monospace face for prompt and window label only. Keep prose and station labels in the sans role, with Pretendard for Korean. The prompt glyph and window marks are decorative and must not take part in the graph's meaning.
+
+## Korean behavior
+
+Keep all station and hub text in Hangul when requested and do not transliterate it to make the terminal frame look more technical. The window label can remain a product name or use a short Korean topic label. The prompt line should be removed if it makes the Korean title wrap awkwardly. Use Pretendard for the title and graph labels; apply mono only to the brief frame metadata.
+
+## Light, dark, and full variants
+
+This is intentionally a dark-frame presentation variant. If a light deliverable is required, remove the shell and use the plain Loop's requested skin instead of building a light terminal skin. The full version may add outside framing text and a source note; its terminal window remains a single frame and the internal graph stays unchanged. Hide terminal window dots and prompt ornament from assistive technology.
+
+## Accessibility
+
+Give the inner SVG its own title and description. The document title describes the subject, not a fake command. Mark decorative window dots and prompt glyphs as hidden from screen readers. Preserve a linear station list after the graph, and keep local scrolling keyboard-accessible with a visible focus indicator. Do not use the frame's color or monospace face as a substitute for an explicit diagram description.
+
+## 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=loop-terminal path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the inner loop satisfies the Loop contract and the frame does not alter geometry against source values and this guide; a matching ID alone does not prove those properties. Inspect desktop and narrow viewport screenshots; run humanizer checks over the prompt, title, and diagram text. If the user requested a light skin, verify that the shell has been omitted and plain Loop tokens used.
+
+## Anti-patterns
+
+- Adding a glowing cyan/purple shell or a fake syntax-highlighted log.
+- Presenting an invented command as though it ran.
+- Putting terminal controls or a caret into the graph's semantics.
+- Reflowing loop stations to fit the frame instead of preserving the base geometry.
+- Using a light terminal theme when the plain light Loop is clearer.
+- Making every text role monospace.
+- Letting frame ornament alter screen-reader reading order.
+
+## Related references
+
+[Loop](type-loop.md) · [Terminal primitive](primitive-terminal.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md) · [Motion guide](motion.md)

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

@@ -0,0 +1,54 @@
+# Loop
+
+Catalog ID: loop
+
+## Purpose and selection
+
+Use a loop when stages form a real recurring cycle and the last step returns to the first. A central hub represents shared state accumulated by the cycle: policy, memory, evidence, or a common record. Solid clockwise ring arrows show operating flow; optional inward dashed spokes show station write-backs to the hub.
+
+## Exclusions
+
+Use a flowchart when the process can terminate or branch without returning, a lifecycle state diagram when a subject transitions between states, and process when the sequence is one-way. Do not force a terminal step into a cycle or add a hub just to occupy the center.
+
+## Content schema
+
+Provide 5–8 ordered stations in clockwise order; each station has a name and optional sublabel, short write-back label, and at most one focal flag. Provide exactly one hub with a name and one concise explanation. State that the last station truly returns to the first. Any spoke must identify what shared state its station writes. Add an optional title and subtitle.
+
+## Deterministic layout recipe
+
+Use a centered 1040 × 680 viewBox with hub center C=(520,340), ring radius R=240, station boxes 160 × 64, and a 200 × 104 hub. For N stations, place station k at angle -90° + k·360°/N, so station 0 is at top and subsequent stations proceed clockwise. Compute ring/box intersections and connect adjacent stations with same-radius clockwise circle arcs; the final arc closes to station 0. Calculate the inward radial spoke endpoints from the station and hub rectangle boundaries, leaving a 6px gap before the hub. The outer margin must include station boxes, strokes, marker tips, and at least 64px clear space. Snap boxes to the 4px grid while preserving symmetry; keep circle intersections to consistent precision.
+
+## Encoding rules
+
+Stations use paper fill and ink border. The hub alone may use a solid ink fill with paper text. At most one focal station uses accent tint and outline. Ring flow is solid muted and clockwise; write-back spokes are dashed and visually lighter. Keep spokes radial and distinct from ring arcs. Optional spoke labels stay beside the path with a paper mask and 6–10px visible gap. The circular arcs and radial spokes are documented type-specific exceptions to the usual orthogonal connector rule; never mix connector grammars around the ring.
+
+## Korean behavior
+
+Use short Korean station names and sublabels, preserving the domain meaning and clockwise order. Make the hub subtitle a plain phrase, not a sentence fragment with unexplained acronyms. Use Pretendard for all Hangul. Mono is limited to short IDs and technical labels. Do not rotate station text; when it cannot fit, shorten with user approval or divide the cycle into overview and detail.
+
+## Light, dark, and full variants
+
+Keep positions and semantics identical across skins. The hub remains the highest-contrast shared-state element in both; write-back spokes remain dashed and secondary. Full editorial adds a framing title, purpose sentence, and optional source note outside the SVG. It does not add a second hub or more stations. Static is the default; motion requires an explicit request and must follow the motion guide's reduced-motion rules.
+
+## Accessibility
+
+Describe station order, cycle closure, hub meaning, focal station, and write-back direction in SVG text. Provide a linear ordered list as an alternative to the circle. Distinguish the return edge by arrow direction and the write-backs by dash, not color alone. Ensure labels do not collide with the hub or spokes.
+
+## 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=loop path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify 5–8 stations, one hub, equal angular intervals, closure, marker landing, radial spoke clearance, focal count, and viewBox margin against source values and this guide; a matching ID alone does not prove those properties. Inspect the screenshot at final output size and run humanizer checks on every visible label.
+
+## Anti-patterns
+
+- A cycle with no true return edge.
+- Two hubs or no named hub meaning.
+- Uneven station angles with no semantic reason.
+- Straight spokes with solid styling or ring paths that cross the hub.
+- Orthogonal sections mixed into the circular ring.
+- More than eight stations or long paragraphs inside station cards.
+- Multiple focal stations that compete for the first read.
+- Movement or animation used to hide a confusing static layout.
+
+## Related references
+
+[Style guide](style-guide.md) · [Output spec](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md) · [Motion guide](motion.md) · [Terminal frame variant](type-loop-terminal.md) · [Semantic patterns](semantic-patterns.md)

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

@@ -0,0 +1,54 @@
+# Marimekko chart
+
+Catalog ID: marimekko
+
+## Purpose and selection
+
+Use a Marimekko chart for a two-way part-to-whole view: column width represents each category's share of the total, segment height represents each series' share within that category, and each segment's area therefore represents the joint share. It answers which categories are large and how their internal composition differs.
+
+## Exclusions
+
+Use a treemap for one part-to-whole hierarchy, a 100% stacked bar when category widths should be equal, a grouped bar when comparing series totals across categories, and a table when precise ranking is primary. Do not use categories with different units in one column. More than eight categories or five series usually makes cells too narrow to label.
+
+## Content schema
+
+Supply a total and unit; 3–8 ordered categories; 2–5 ordered series; and an amount for every present category-series pair. State the source, period, rounding policy, missing-series policy, and one optional focal cell. Categories and series must use stable IDs; order series by descending overall total, with source order as the tie-breaker. Bind every data segment to category ID, series ID, and amount; bind every label, caption, and key to the same identifiers. Missing pairs are omitted, not represented as zero-height rectangles.
+
+## Deterministic layout recipe
+
+Use a 1000 × 500 SVG with plot bounds x=40..956 and y=40..420. Start with 4px constant gutters between columns; compute each column width from its category total divided by the grand total, after subtracting all gutters, then snap boundaries to whole pixels while preserving the total plot width. Each column spans the full 380px plot height. Within a column, order series consistently by descending overall total and allocate segment heights by within-column share. Segments tile from top to bottom with no vertical gaps; shared boundaries use a hairline. Use a 4px grid for plot constants and column edges; data-driven segment boundaries use whole pixels and are not snapped. Below the plot, place each category name and whole-share under its column; reserve a lower strip for series keys and a source line. For screens narrower than 760px, preserve chart width and use a local horizontal scroller.
+
+## Encoding rules
+
+Column width, within-column height, and segment area all state related facts, so every dimension must be derived from the declared amounts. Keep one ink-opacity level per series in a rank-ordered neutral ramp and one focal accent segment at most. Print the amount and within-column share inside sufficiently large segments; the focal label may clarify its share of that category to avoid implying a whole-total share. Narrow cells use an information mark only when it fits fully; explain that cell in the key. Never widen a column or pad a segment for text. State that width is category share, height is within-category share, and area is joint share. The chart shows a whole: merge a small tail only into a named Other category or series and disclose it.
+
+## Korean behavior
+
+Use Hangul for category and series names when intended for Korean readers. Retain data units and official product names. Use Korean number grouping and percentages consistently, and distinguish within-category percentages from whole-total shares in both captions and labels. Pretendard is used for names; the mono role is for amounts, units, and concise IDs. Preserve stable category order while wrapping captions at phrase boundaries. Never rotate or abbreviate labels into ambiguity.
+
+## Light, dark, and full variants
+
+Light and dark layouts share every column width, segment height, amount, category order, series order, and focal choice. Use identical ramp opacity values while semantic paper/ink tokens invert; check text contrast on each series fill. Full editorial may add a framing headline, one takeaway, and source/date note outside the plot, without changing the geometry. Set a 760px minimum canvas inside a local scroller; do not shrink data marks to fit a phone viewport.
+
+## Accessibility
+
+Add SVG title and description identifying the total, unit, period, category and series counts, both encodings, and any focal cell. Supply a companion data table with whole and within-category shares. Never use fill tone alone to identify a series; the keys name the series and repeat the same visual token. Explain information-mark cells in text and ensure every narrow column can still be identified by its caption and table row.
+
+## 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=marimekko path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify column-width, segment-height, and joint-area shares from amounts; check tiling, constant gutters, stable series order, complete bindings, focal count, marker containment, and total reconciliation against source values and this guide; a matching ID alone does not prove those properties. Inspect a narrow viewport screenshot and a full-size export; run humanizer checks on all visible text.
+
+## Anti-patterns
+
+- Equal-width columns when category totals differ.
+- Unequal column heights or gaps between segments.
+- Reordering a series inside only one column.
+- Drawing an absent category-series pair as a zero-height segment.
+- Dropping a category or series without an explicit named aggregation.
+- Expanding marks to fit labels or using rotated type in slivers.
+- Claiming area is comparable while width or height has been manually adjusted.
+- Naming ramp direction by lightness when light and dark invert it.
+
+## Related references
+
+[Treemap](type-treemap.md) · [Heatmap](type-heatmap.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md)

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

@@ -0,0 +1,54 @@
+# Medallion data tiers
+
+Catalog ID: medallion
+
+## Purpose and selection
+
+Use this type for a governed data pipeline with ordered quality and access tiers, such as landing, raw, cleaned, curated, and archive. Each tier card states the container, format, accountable writer, and a concrete sample payload. Promotion arcs describe transformations from one adjacent tier to the next; optional path cards describe write methods.
+
+## Exclusions
+
+Use High-Level for a full platform topology, data-flow for role-by-step responsibilities, and Marimekko for measured composition. Do not use medallion for an arbitrary row of services or for an ungoverned process with no data-quality promotion. Do not imply a promotion or access policy that the source has not established.
+
+## Content schema
+
+Provide 3–5 ordered tiers, each with a stable name, storage bucket or location, exactly one focal flag across the diagram, and fields for tool, format, writer, and one or two example payloads. Provide one promotion label for every adjacent pair and declare normal, focal, or lifecycle semantics. Include a sample-data caption. Add zero to two optional write-path cards with tag, method title, and short description. Choose exactly one focal tier; if none is supplied, ask which analytical or policy pivot should lead.
+
+## Deterministic layout recipe
+
+Use a horizontal tier strip with 172 × 380px cards, 16px gaps, 16px left inset, and an 80px arc band above the cards. Place cards at y=80, with centers evenly spaced across the strip. The canonical five-tier SVG is 1040px wide; derive width from tier count and gaps, and retain a 100px right legend margin. Reserve a 16px gap and 56px height per path card below the tiers. Promotion arrows are cubic curves over the top, from the center of one tier to the next; control points sit at y=0, their labels at y=50. This arc is the defining connector and a specific exception to orthogonal routing. The total height covers arc band, cards, optional path row, legend, and bottom margin. Use a deterministic 4px grid for card and frame geometry.
+
+## Encoding rules
+
+Use quiet neutral cards with a 40px header band and four labeled information fields; keep the example payload visibly separate near the bottom. Styles distinguish outer input, ordinary tier, the one focal tier, and cold archive. The focal tier gets a restrained accent outline and tint; its incoming arc may use accent, while a terminal lifecycle arc remains dashed. Use at most two justified custom colors outside the focal tier. Promotion is left-to-right only. Do not put transformations into path cards: path cards name how data moves, while tier fields describe what the tier contains.
+
+## Korean behavior
+
+Use concise Hangul names for stages and field headings, with storage identifiers and format names preserved as authored. Set the field order consistently across every card so Korean readers can compare the same slot from tier to tier. Wrap long tool, format, and writer strings to two lines within the field width; add an adjacent expanded description rather than shrinking labels. Use Pretendard for Korean text and mono for technical formats, bucket paths, and abbreviated tags. State all transformations in language the audience uses.
+
+## Light, dark, and full variants
+
+Light and dark variants retain card size, order, fields, arcs, sample payloads, and focal tier. In dark mode invert surface roles, retain dashed archive treatment, and lighten custom colors only as required for contrast. Full editorial adds an outer framing title, subtitle, and optional summary cards outside the tier strip. It must not omit a tier or reorder transformations. Export to slides with the Office guide's safe margins and a table fallback for field-level detail.
+
+## Accessibility
+
+Add an SVG title and description that state the number and order of tiers, promotion meaning, focal tier, and terminal archive semantics. Every card field needs a visible heading; do not rely on color to identify the focal tier or lifecycle. Provide a linear text list or table of tier fields, particularly when the figure will be inserted in Office. Keep arc labels clear of the curve and the card text.
+
+## 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=medallion path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify tier count and order, four fields per tier, one sample payload per tier, exactly one focal tier, adjacent left-to-right promotions, path-card cap, and marker landing against source values and this guide; a matching ID alone does not prove those properties. Compare the visible data with the source before export, inspect the screenshot, and run humanizer checks on all text.
+
+## Anti-patterns
+
+- No unique payload example on a tier.
+- More than one focal tier or a guessed focal policy.
+- Bidirectional or non-adjacent promotion arcs.
+- Straight through-gap arrows instead of top arcs.
+- A cold dashed treatment on a non-archive tier.
+- More than two custom-colored components or color-coded connector semantics.
+- Path cards that explain what a tier stores instead of how data is written.
+- Text too long for the fixed tier card, hidden behind an export crop.
+
+## Related references
+
+[Style guide](style-guide.md) · [Output spec](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md)

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

@@ -0,0 +1,59 @@
+# Nested containment
+
+**Catalog ID:** `nested`<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 Nested when meaning comes from one boundary being inside another: scope inheritance, trust zones, blast radius, workspace ownership, or a document/configuration cascade. The outside ring is the broadest scope; each inward ring narrows it. Select this only when every level has exactly one child scope. For branching parent/child structures, use Tree or Org chart; for broad, non-nested infrastructure zones, use Architecture.
+
+## Exclusions
+
+Do not use concentric rings to show steps, quantities, cross-links, peer groups, or several children of one parent. Do not put unrelated facts inside a ring merely to fill space. If a boundary has a side branch, split the diagram or switch to a grammar that supports branching.
+
+## Content schema
+
+```yaml
+title: "Which policy applies here?"
+levels:                         # outermost to innermost; 2–6, preferably 3–5
+  - { id: org, label: Organization, detail: "Baseline controls" }
+  - { id: team, label: Team, detail: "Team overrides" }
+  - { id: repo, label: Repository, detail: "Local configuration" }
+  - { id: task, label: Task, detail: "Current request" }
+focal_id: task                  # optional; at most one
+annotations: []                 # optional; at most two short callouts
+```
+
+Every level needs a stable ID and concise name. `detail` is optional and must fit inside that level without shrinking the text. A level may contain a single short example or file marker; it may not introduce another hierarchy.
+
+## Deterministic layout recipe
+
+Use a 1000×600 SVG viewBox. Place the outer boundary at `(40, 56)` with width `920` and height `488`. For `n` levels, use an inset of 32px horizontally and 28px vertically per level: level `i` has `x=40+32i`, `y=56+28i`, `w=920−64i`, `h=488−56i`. Draw outer-to-inner so later rings sit above earlier strokes. Put each label in a small paper-backed tab on the top-left border, aligned to a common x inset; center one short detail line inside the remaining clear region. Keep text and any icon away from the next ring. At 6 levels, omit inner detail rather than overlap it. Place up to two annotations outside the rings and connect with a thin leader that touches no other boundary.
+
+## Encoding rules
+
+Containment is position and enclosure only. Use a consistent gap between rings, a quiet neutral stroke ramp from outer to inner, and one accent boundary at most for the selected focal scope. Do not vary ring width, area, or opacity to imply size or importance. Use a simple folded-corner/file mark only when the enclosed item is genuinely a document or configuration. The output remains static.
+
+## Korean behavior
+
+Use the same ring geometry for Korean and English. Prefer short Korean scope nouns; keep product names, paths, and identifiers unbroken. Center text in the available interior and use the Korean reference's line height. If a Korean label needs a second line, wrap at a word boundary and keep the label tab on one line; shorten or omit secondary detail before reducing type size.
+
+## Light, dark, and full variants
+
+Light and dark variants use identical coordinates, labels, and hierarchy; switch only the shared surface, ink, rule, and accent tokens. Keep the accent on the same level in both. The full variant may place the unchanged ring diagram in the editorial frame with one title, a short reading note, and no more than two callouts. Do not add extra rings to use the frame.
+
+## Accessibility
+
+Give the SVG a concise title and a description that names the containment order from broadest to narrowest. Provide a text outline in DOM order matching outer-to-inner order. Each boundary must remain distinguishable without color through labels, enclosure, and stroke contrast. Decorative icons are hidden from assistive technology. Keep labels in reading order and preserve visible focus only if an interactive host adds controls; the diagram itself has none.
+
+## 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=nested 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 numeric contract is registered; review containment order, level budget, bounds, and label tabs here. 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 six rings, or inconsistent gaps that make nesting look accidental.
+- Branches or cross-links represented by squeezing sibling scopes into one ring.
+- A title or detail that crosses a boundary or sits over the next label tab.
+- Accent on multiple levels; it erases the hierarchy of attention.
+- Fill gradients, shadows, or oversized nested cards that compete with the boundaries.

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

@@ -0,0 +1,58 @@
+# Org chart and responsibility map
+
+**Catalog ID:** `org-chart`<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 Org chart when the reader needs to know who owns work, how to invoke an owner, where escalation goes, or which responsibility is still unstaffed. It supports people, teams, agents, queues, and accountable roles. Use Tree for a generic hierarchy where ownership and invocation are irrelevant; use Swimlane or Process for work that moves over time.
+
+## Exclusions
+
+This grammar shows one reporting or responsibility parent per node. It does not show arbitrary dependencies, many-to-many assignments, timelines, or task steps. A missing owner is not an ordinary active node: represent it as a visibly optional/setup gap. Cross-functional routing belongs in a separate flow diagram.
+
+## Content schema
+
+```yaml
+title: "Support ownership"
+nodes:
+  - { id: intake, name: Support desk, kind: front-door, invocation: "/help", scope: "Triage · routing" }
+  - { id: platform, parent: intake, name: Platform pod, kind: team, invocation: "#platform", scope: "Runtime · deploys" }
+  - { id: identity, parent: platform, name: Identity owner, kind: owner, invocation: "IAM queue", scope: "Login · access", status: active }
+  - { id: after-hours, parent: intake, name: After-hours owner, kind: owner, invocation: "—", scope: "Not assigned", status: gap }
+escalations: ["Security approval required for production access"]
+```
+
+Each node has a stable ID, visible name, parent (except the single root), role kind, concise scope, and optional invocation route. `status` is `active`, `optional`, or `gap`; never imply a gap is staffed. Use at most two short escalation notes outside the tree.
+
+## Deterministic layout recipe
+
+Use a top-down layout. Put the root at the first tier, then children in stable input order at each next tier. Place every tier on a shared y baseline and distribute its node centers evenly from the left safe margin to the right safe margin; compute each tier's x positions from its child count, not from manual nudges. Draw connectors first: vertical drop from each parent to a horizontal bus, then vertical drops to its children. Use right-angle paths and leave enough space between tiers for the bus and labels. Keep nodes the same width within a tier; size the canvas from the largest measured label plus fixed padding. Cap the view at 12 visible nodes, 4 tiers, and 5 direct reports per parent. Group larger teams into a pod node and link a second detail chart.
+
+## Encoding rules
+
+Give one root/front door the focal treatment. Team/pod nodes use the neutral team treatment; owner nodes use the owner treatment; approval gates use the security treatment but remain separate from reporting lines. Dashed outlines distinguish optional or unconfigured roles. Each node should answer name, invocation, and scope in that order; omit an unavailable invocation as an explicit unavailable marker. Put escalation notes in a side callout or footer, never as phantom reports. No arrows or connector labels are needed for a pure org chart.
+
+## Korean behavior
+
+Use Korean role names and scope words where that is the team's language. Keep handles, slash commands, queue names, and IDs in their original spelling and do not break them across lines. Use one or two intentional name lines and no more than two short scope lines. Keep labels centered in identical node geometry across languages; if the text does not fit, shorten the role or split the chart by pod.
+
+## Light, dark, and full variants
+
+Light and dark share the same tree, node dimensions, and status encoding. Change only shared tokens; keep dashed gaps dashed and keep the single focal owner consistent. The full variant may add an editorial heading and a compact escalation note or coverage summary below the same chart. It must not add people or alter responsibility to fill the frame.
+
+## Accessibility
+
+Use a titled SVG with a description of the root, reporting direction, and any visible coverage gap. Provide a linear text list in DOM order: parent before children, with each node's name, invocation, scope, and status. Do not encode active/gap distinctions by color alone. Connector contrast must meet the shared non-text contrast rule, and node text must remain readable at slide scale.
+
+## 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=org-chart 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 root/parent links, tier and report limits, node status, and orthogonal ownership connectors 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
+
+- Using a process lane when the question is ownership, or a reporting tree when the question is sequence.
+- More than 12 nodes, 4 tiers, or 5 reports under one parent without splitting.
+- Treating an unconfigured owner as active or hiding the gap entirely.
+- Identical boxes for the front door, team, owner, and approval role.
+- Job-description paragraphs, repeated handles in callouts, diagonal lines, or floating legends.

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

@@ -0,0 +1,72 @@
+# Secure paved-road architecture
+
+**Catalog ID:** `paved-road-animated`<br>
+**Semantic pattern:** secure paved road; visual grammar: Architecture.<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 a supported deployment route must be distinguished from forbidden ingress or bypass attempts. Make trust boundaries, actor identities, the privileged approval gate, isolated runtime, and audit destination explicit. It is an Architecture diagram with optional step reveal; it is not a new free-form flowchart. Use a regular Architecture figure when trust enforcement and allowed/blocked routes are not the point.
+
+## Exclusions
+
+Keep to at most three trust zones, eight components, ten paths, two blocked paths, and one privileged gate. Do not show credentials or secret values. A denied path must stop at the boundary; it must not reach the protected runtime or rejoin the authorized route. Use a separate governance/control catalog when detailed controls and exceptions exceed the one-gate overview.
+
+## Content schema
+
+```yaml
+title: "Secure deployment route"
+zones:
+  - { id: public, label: Public ingress }
+  - { id: build, label: Build and governance }
+  - { id: production, label: Isolated runtime }
+components:
+  - { id: developer, zone: public, label: Developer, identity: Signed commit }
+  - { id: attacker, zone: public, label: Untrusted client }
+  - { id: pipeline, zone: build, label: CI pipeline }
+  - { id: gate, zone: build, label: Policy gate, role: privileged-gate }
+  - { id: audit-log, zone: build, label: Audit log }
+  - { id: api, zone: production, label: Production gateway }
+  - { id: db, zone: production, label: Core database }
+  - { id: soc, zone: production, label: Security monitoring }
+paths:
+  - { id: deploy, from: gate, to: api, kind: permitted, label: Approved artifact }
+  - { id: bypass, from: attacker, to: production-boundary, kind: blocked, label: Denied at boundary }
+  - { id: audit, from: gate, to: audit-log, kind: audit }
+  - { id: monitoring, from: audit-log, to: soc, kind: audit }
+steps: ["signed intake", "build and sign", "gate approval", "blocked bypass", "audit record"]
+```
+
+Every component belongs to one labeled zone. Each path declares endpoints, permitted/blocked/audit meaning, and a text label where the meaning is not self-evident. Keep identities as roles or claims, never secret values. `steps` are a reveal order over existing facts, not a second data model.
+
+## Deterministic layout recipe
+
+Use a wide 1160×620 canvas. Allocate three equal vertical trust-zone bands from left to right, separated by strong, labeled boundary rules; if a design has fewer zones, distribute them evenly and keep zone width equal. Put public actors in the first band, build/approval components in the middle, and runtime/data components in the last. Place the privileged gate before the production boundary. Route authorized deployment through that gate and across the boundary; route each blocked attempt to a stop marker just before the boundary. Place audit logging as a separate destination reachable from the approval gate and relevant boundary event, with the monitoring consumer downstream. Draw zone surfaces first, then connectors, then components and labels. Fix component positions across all variants and motion steps. Motion groups reveal the signed input, build/sign, approval/deployment, blocked attempt, and audit event in that order; the final static frame contains all routes.
+
+## Encoding rules
+
+Permitted paths are solid and labeled; blocked attempts use a contrasting dash pattern plus a stop symbol and label; audit events use their own consistent line style. The route and wording carry status as well as color. Accent the single enforcement focus (gate or blocked result), keeping the remaining components neutral. The trust-zone boundary is a structural line, not a decorative container. Show no connector crossing that suggests an unauthorized route entered production.
+
+## Korean behavior
+
+Use short Korean zone titles and actor names; preserve security terms, identity claims, product names, API names, and protocol codes. Keep positive route text distinct from blocked route text with direct verbs. The final description should summarize both approved and rejected paths in Korean. If a Korean note is longer than the available band, move it to a callout outside the zones instead of reducing type.
+
+## Light, dark, and full variants
+
+Light and dark preserve zone order, paths, stop points, and focus; only shared palette tokens change. The full variant may add a compact “why this route is trusted” note outside the architecture bands. All static exports show every boundary and both route classes. Optional motion must use the same final geometry and must not animate a blocked path through a boundary.
+
+## Accessibility
+
+Give the SVG title and description that identify the trusted path, the blocking boundary, the privileged gate, and audit destination. Provide a text alternative listing each permitted and blocked route as `from → to → result`. Patterns, stop symbols, and labels distinguish route classes without color. Step controls are keyboard-operable, announce their state, and preserve a complete no-motion rendering; follow [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=paved-road-animated path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the registered secure-route contract: zone/path budgets and allowed-versus-blocked boundary 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
+
+- A box labeled “security” with no route or enforcement meaning.
+- A blocked arrow that crosses into production or visually rejoins an allowed path.
+- Unlabeled actor identity, an implied secret, or every component styled as equally trusted.
+- More than three zones, eight components, ten paths, or one privileged gate in the overview.
+- A color-only denied state, decorative motion, or an animated final state unavailable in a still/export.

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

@@ -0,0 +1,67 @@
+# Polar chart
+
+**Catalog ID:** `polar`<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 Polar for one nonnegative quantitative series across 4–8 categories whose cyclic order is meaningful: hours in a day, months in a seasonal cycle, or ordered phases that wrap. Radius encodes magnitude; angle encodes category position. Use Radar for several entities measured on the same criteria, Bar for categories without a circular order, and Line for longer ordered time sequences.
+
+## Exclusions
+
+The first version is static and supports one series, 4–8 equally spaced categories, a linear scale starting at zero, and at most one focal category. Do not use it for personality/competency wheels, arbitrary point placement, multiple series, negative values, unequal sector widths, log scales, filled wedges, or a donut baseline. Missing values are unknown, not zero; resolve them before drawing.
+
+## Content schema
+
+```yaml
+title: "Requests by time window"
+unit: "% of daily peak"
+scale: { min: 0, max: 100 }
+start_angle: -90
+clockwise: true
+categories:
+  - { id: night, label: "00–03", value: 32 }
+  - { id: early, label: "03–06", value: 18 }
+  - { id: morning, label: "06–09", value: 24 }
+  - { id: midday, label: "09–12", value: 58 }
+  - { id: peak, label: "12–15", value: 100, focal: true }
+  - { id: afternoon, label: "15–18", value: 82 }
+  - { id: evening, label: "18–21", value: 76 }
+  - { id: late, label: "21–24", value: 45 }
+```
+
+Provide 4–8 uniquely named categories in meaningful order, finite values within the shared range, explicit unit, and optional one-category focus. Keep input order; do not sort by value. The `min` must be exactly zero and `max` finite and positive.
+
+## Deterministic layout recipe
+
+Use a 1000×520 viewBox, center `(500,230)`, and outer radius `R=160`. Draw five circular guide rings at 20%, 40%, 60%, 80%, and 100% of `R`. For category `i` among `N`, calculate `theta = start_angle + s×2πi/N`, with `s=+1` clockwise and `−1` counter-clockwise; convert start angle to radians. Compute `r=R×value/max`, then endpoint `(500+r cos(theta), 230+r sin(theta))`. Draw the faint category spoke to the outer ring and a value ray from center to endpoint. Put category text at radius `R+28`, value text at `R+44`; keep labels horizontal, with start/end/middle anchor chosen by the side of the circle. Place scale labels on the top spoke only. A value of zero gets a printed zero but no ray or endpoint marker. Drawing order: paper, rings, spokes and ring labels, non-focal rays, focal ray, markers, category/value labels, legend.
+
+## Encoding rules
+
+Only ray length encodes value. Markers have constant radius; rings and spokes are structural guides, not data. Use muted rays for ordinary categories and one accent ray at most. Do not fill sectors or vary line width by value. Keep the category order and the common zero baseline visible. Store each category's declared value and computed angle/radius as machine-readable metadata for `verify-type`.
+
+The polar verifier contract is carried in SVG attributes: put `data-polar-chart` and the shared `data-polar-cx`, `data-polar-cy`, `data-polar-radius`, `data-polar-min`, `data-polar-max`, `data-polar-start-angle`, `data-polar-clockwise`, `data-polar-radius-encoding="linear"`, and `data-polar-inner-radius="0"` on the root SVG. Wrap each category in a `<g>` with `data-polar-category`, `data-polar-index`, and `data-polar-value`; add `data-polar-focal="true"` only to the single focal category. Give every ray, spoke, and rule line exactly its corresponding `data-polar-ray`, `data-polar-spoke`, or `data-polar-rule` role; mark all five rings with `data-polar-ring`, endpoints with `data-polar-marker`, and value labels with `data-polar-value-label`. The optional canvas rectangle is identified by `data-polar-background`. Keep raw coordinates readable to the checker: no transforms or CSS geometry that could move a verified mark.
+
+## Korean behavior
+
+Keep category order and angles identical across language variants. Prefer short labels; place longer Hangul labels on one or two horizontal lines outside the ring. Keep units in the subtitle or a single legend statement rather than repeating them in every value label. Use Korean numeral formatting consistently, and do not break time ranges or units across lines.
+
+## Light, dark, and full variants
+
+Light/dark keep identical values, coordinates, order, and focus; only shared tokens change. The full variant may add an editorial frame and short interpretation cards, but chart geometry remains fixed. Static output only; do not add hover, drag, or animation.
+
+## Accessibility
+
+The SVG description names the measure, shared scale, category order, and maximum category. Include an ordered text alternative with category/value pairs and unit. Keep all labels horizontal, use numeric labels so color is not required to read the chart, and ensure spoke/ray contrast against each skin. Decorative rings are hidden from the accessible name.
+
+## 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=polar path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the five rings, spokes, angles, ray lengths, zero values, unique labels, and light/dark geometry parity from the declared input 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
+
+- Truncated nonzero inner baseline, donut hub, filled wedge, or area encoding.
+- Sorting categories by magnitude or placing unequal angles without a declared reason.
+- Treating missing data as zero, adding a minimum visible ray, or plotting multiple series.
+- Rotated/tangent labels, category-specific colors, or more than one accent target.
+- Using polar coordinates when circular order adds no information.