@litfamily/lithermes 1.0.8 → 1.0.10

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

@@ -0,0 +1,60 @@
+# Scatter plot
+
+**Catalog ID:** `scatter`<br>
+**Companion catalog entries:** [Bubble](type-bubble.md) · [Beeswarm](type-beeswarm.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 Scatter when the relationship between two continuous variables is the point: correlation, clusters, outliers, or high/low performers. Choose Bubble only when a third, positive magnitude matters; its area needs a separate encoding contract. Choose Beeswarm when one distribution and each observation matter. If a chart is plotting scientific measurements as a scientific result, use the scientific-visualization workflow.
+
+## Exclusions
+
+Use 5–30 points for the standard scatter. Fewer points are usually clearer in prose or a table; more points become a density problem and should be binned or shown with Beeswarm if every observation is meaningful. Do not add a third size scale, unreported jitter, a forced fit line, or labels on every point. Keep the meaning and range of both axes explicit.
+
+## Content schema
+
+```yaml
+title: "Service latency and error rate"
+x_axis: { label: p95 latency, min: 0, max: 500, unit: ms }
+y_axis: { label: Error rate, min: 0, max: 5, unit: "%" }
+points:
+  - { id: checkout, label: Checkout, x: 260, y: 2.8, focal: true }
+  - { id: search, label: Search, x: 180, y: 0.9 }
+trend: none                    # optional; only when supported by the data
+quadrant_guides: false         # optional median guides
+```
+
+Every point has a stable ID and finite x/y values within declared bounds. Label the focal point and no more than two additional outliers. An optional trend line must have a stated model or honest descriptive purpose. Optional median guides label all four regions and remain visual aids rather than new variables.
+
+## Deterministic layout recipe
+
+Use a 1000×500 viewBox with plot bounds x=80..960 and y=40..420. Map each coordinate linearly to those bounds: x increases left-to-right, y increases bottom-to-top. Draw 4–6 equally spaced ticks on each axis, with grid rules aligned to ticks. Give standard points a fixed radius of 5px and a single focal point 6px. Place at most three point labels on paper-backed backgrounds, trying a fixed order of offsets (above-right, above-left, below-right, below-left) and selecting the first that clears prior labels and axes. Never shift the point center. Draw an optional muted dashed trend rule only after confirming that its direction is supported by the data. Reserve the bottom footer for a compact legend or source footnote.
+
+## Encoding rules
+
+Point position encodes x and y. Point size and fill opacity are fixed; only one point may use the accent. Add a fit line only if it clarifies a real pattern, and never use it to imply causation. Include zero in an axis when absolute position needs it; if a useful range omits zero, print the visible bounds prominently. Keep units and scales visible, note any omitted observations, and bind each label/tick to its associated data point or value. Bubble size and beeswarm packing rules live in their companion guides.
+
+## Korean behavior
+
+Use concise Korean axis titles with units and a consistent number format. Keep values and `%`, milliseconds, or other units together. Use Pretendard for prose and the shared mono face for ticks/identifiers. For Korean point labels, use a short phrase and wrap only on word boundaries; a longer name belongs in a side key rather than over the cloud. Preserve Latin service IDs exactly.
+
+## Light, dark, and full variants
+
+All skins preserve point coordinates, scales, ticks, focal point, and label bindings. Light/dark switch shared tokens; confirm grid and mark outlines against each paper surface. Full adds a small editorial title and one interpretation note around the unchanged plot, not a new scale or data series.
+
+## Accessibility
+
+Provide title and description naming both variables, units, bounds, the focal point, and any trend fit. Supply a text table with one row per item and x/y values. Mark focus in text as well as by accent, and ensure circles have visible strokes at presentation size. Keep quadrant labels, if used, explicit rather than relying on position alone. See [Accessibility](accessibility.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=scatter 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 scatter proof is registered; manually compare point coordinates and tick labels with the declared axis bounds. 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 30 unlabeled-density points, one label per mark, or silently omitted extremes.
+- A trend line forced onto scattered data or interpreted as causal evidence.
+- Bubble size used without the separate Bubble contract, or a third variable smuggled into color.
+- Moving a point to prevent collision, or using inconsistent bounds for different points.
+- Truncated axes with no printed range, or axes whose units are unclear.

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

@@ -0,0 +1,66 @@
+# OAuth refresh sequence
+
+**Catalog ID:** `sequence-oauth`<br>
+**Parent grammar:** [Sequence](type-sequence.md)
+
+## Purpose and selection
+
+Choose this focused sequence variant when a client makes a bearer-authenticated resource request and the important story is the invalid-token response, refresh, and retry. It keeps the normal request/response chronology while making the token-valid and refresh branch legible. Use the general sequence guide for other protocols, or a state machine when the subject's legal states matter more than messages between actors.
+
+This drawing documents an exchange; it is not an OAuth threat model, a complete authorization-code grant, or proof that an implementation follows a security profile. Link a separate security review when those claims matter.
+
+## Content schema
+
+Prepare a small ordered record before drawing:
+
+- **Participants:** stable id, display name, role, and optional short system qualifier. Usual roles are client, resource API, and authorization service.
+- **Messages:** order, sender, receiver, kind (`call`, `return`, or `async`), short protocol label, and optional outcome/status. Include the bearer request, resource result, token refresh exchange, and one retry only where the brief requires it.
+- **Branch:** one `alt` fragment with two guards: the valid-token success region and the expired/invalid-token region. Record the condition and resulting message in each region.
+- **Security note:** identify whether credentials are illustrative or redacted. Never place a real access token, refresh token, client secret, or personal data in visible text, metadata, examples, or screenshot filenames.
+
+Keep message labels to method/path, status, and a short payload noun. Put detailed claims in a caption or companion prose, not on every arrow.
+
+## Deterministic layout recipe
+
+1. Place participants left-to-right by first interaction; keep the client at left, resource API in the middle, and authorization service at right when those are the actors. Draw participant boxes once and dashed lifelines straight down.
+2. Allocate one vertical slot per message in chronological order. Reserve enough height for the `alt` tab, guard labels, divider, and both branch messages before placing arrows. Align each message to the 4 px layout grid and keep at least 24 px between message baselines.
+3. Put the bearer request and its first response above the branch. Frame only the lifelines that participate. Inside `alt`, put `[token valid]` in the first region and an explicit expired/invalid-token guard in the second; separate the regions with a dashed rule. Leave at least 16 px between the divider and nearby messages.
+4. In the failure region, show the unauthorized return, the refresh call and response, then one resource retry and its return. Use the auth participant for the refresh exchange. Keep the activation bar open only while that participant processes the exchange.
+5. Put any audit/event notification after the user-facing result. Draw it as a dashed line with an open head; returns are dashed with filled heads, and synchronous calls use solid filled heads.
+6. Route labels into clear space without moving message y-values to conceal crowding. If the 5-lifeline, 12-message, 1-fragment, or 2-region budget is exceeded, split the refresh detail into a second figure.
+
+## Visual encoding
+
+Use the parent sequence grammar for line types, activation bars, branch frames, and arrowheads. Keep request calls solid, synchronous responses dashed with filled heads, and one-way events dashed with open heads. Use the accent for at most one headline success message; the success and error branches must remain distinguishable from their guard text and status labels without color. Operator tags (`ALT`, `OPT`, `LOOP`) use the mono role.
+
+The refresh token itself is never visualized. Show only the protocol action, such as `POST /token · refresh`, and the resulting status. Do not imply that refresh always succeeds: if failure handling is in scope, add a clearly bounded second figure or use a complete branch with a labeled failure result.
+
+## Korean text
+
+Use Pretendard for participant names and Hangul phrases; use the bundled mono role for method names, paths, statuses, guards, and identifiers. Break long labels at phrase boundaries and keep `GET /resource`, status codes, and token-related protocol terms intact. Keep guard wording short enough to remain inside the frame. Follow [Korean typography](korean-typography.md) for mixed Hangul/Latin spacing, baseline, and number treatment.
+
+## Light, dark, and full variants
+
+All three variants preserve the participant order, message order, branch guards, and geometry. Light and dark swap semantic surface and ink tokens only. In the full editorial variant, add a concise title, one explanatory caption, and a legend for call/return/async/fragment if needed; the frame must not add extra branches or suggest a security guarantee. Maintain arrowhead contrast in both skins.
+
+## Accessibility
+
+Provide an SVG title and a description that narrates the happy path, the invalid-token branch, and the retry outcome in order. Use visible guard and status labels as redundant cues for line style. Keep text outside lifelines where possible, maintain readable label contrast, and ensure open versus filled arrowheads remain visually distinct at export size. Do not rely on accent color to identify success or failure.
+
+## 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=sequence-oauth path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the two-region refresh contract and message/arrow semantics against source values and this guide; a matching ID alone does not prove those properties. Review the rendered light, dark, and full captures at the intended slide size; a green structural check does not confirm that guard labels are readable.
+
+## Anti-patterns
+
+- Showing real credentials or a token value.
+- Omitting the invalid-token status before refresh, or drawing refresh as a user-facing resource response.
+- Combining both outcomes into an unlabeled arrow cluster.
+- Drawing returns with solid calls' line grammar or async events with filled heads.
+- Adding multiple retries while leaving the retry policy unspecified.
+- Treating this focused exchange as a complete OAuth security analysis.
+- Moving an arrow to make its label fit or using color alone to distinguish branch outcomes.
+
+## Related references
+
+[Sequence](type-sequence.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,63 @@
+# Sequence
+
+**Catalog ID:** `sequence`<br>
+**Common references:** [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Motion](motion.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [PPTX/DOCX](office-pptx-docx.md) · [Verifier guide](verifier-guide.md)
+
+## Purpose and selection
+
+Use Sequence for requests, responses, events, and interactions among actors when message order and timing are load-bearing: API calls, auth refresh, or incident reconstruction. Use State Machine for one subject changing state, Process for steps across owners, or Flowchart for decision logic without actor-to-actor messages.
+
+## Exclusions
+
+Support up to five lifelines and twelve messages. Use at most one combined fragment by default; a second is allowed only when each is a single-region `opt` or `loop`. `alt` has at most two regions, nesting depth is one. Creation/destruction, duration bars, parallel/critical/break/ref operators are out of scope; split an over-budget exchange into overview and detail.
+
+## Content schema
+
+```yaml
+title: "Token refresh"
+actors: [{ id: app, label: Client }, { id: api, label: API }, { id: auth, label: Auth service }]
+messages:
+  - { from: app, to: api, kind: call, label: "GET /resource", step: 1 }
+  - { from: api, to: auth, kind: call, label: "Validate token", step: 2 }
+  - { from: auth, to: app, kind: return, label: "New token", step: 3, focal: true }
+fragments:
+  - { kind: alt, guards: ["token valid", "token expired"], start_step: 2, end_step: 3 }
+```
+
+Actor order is explicit and stable. Each message declares source, target, kind (`call`, `return`, `async`), concise label, sequence number, and optional focal state. Fragments declare participants, region guards, and covered message range. Returns must pair with a synchronous call; async messages are one-way.
+
+## Deterministic layout recipe
+
+Place actor boxes in one horizontal row, evenly centered across a 1000px-wide canvas with equal lifeline gaps and symmetric outer margins. Extend dashed lifelines from the actor row to the bottom safe margin. Time runs top to bottom: place message `k` at a fixed 32px vertical interval below the previous message, with enough room for its label and any activation change. Sync calls use horizontal solid arrows; returns use horizontal dashed arrows; async sends use dashed arrows with open heads. Draw narrow activation bars on the receiving lifeline from call receipt through return. Self-calls use a short right-facing U-loop. A branch frame spans only participating lifelines and the message interval; its tab and guard sit above the first message in each region. Reserve at least 24px between messages and place labels above or below their own line without crossing another lifeline.
+
+## Lifeline binding
+
+Mark each participant box with a unique `data-node-id`. Draw one dashed SVG `<line>` per participant with `data-lifeline-for` set to that same ID; its `x1` and `x2` are the box center, `y1` is the box bottom, and `y2` reaches at least the last message row. Every message route carries `data-from` and `data-to`; its first and final points land on the corresponding lifeline x coordinates. Keep message routes in their visual top-to-bottom order in the SVG. The sequence verifier checks the lifeline map, box alignment, final-message coverage, endpoint binding, and order. Lifeline/message intersections are intentional and excluded from generic arrow-crossing totals.
+
+## Encoding rules
+
+Call: solid line and filled head. Return: dashed line and filled head. Async: dashed line and open head. The one primary success message may use accent; do not accent both branches. `alt`, `opt`, and `loop` operators are printed in mono and placed in a light frame with a clear guard. Every activation bar closes. All arrows point down in time; return arrows still travel between actors horizontally and appear later in the vertical sequence.
+
+## Korean behavior
+
+Keep actor labels and endpoints stable. Use short Korean verb phrases for messages and preserve API paths, token names, and protocol codes. Wrap labels only within their lifeline gap; if they collide, shorten the message or add vertical space. Operator names and guards use the same mono role in both languages; provide Korean alternatives without changing step order.
+
+## Light, dark, and full variants
+
+All variants have identical actors, messages, activation spans, fragments, order, and focus. Light/dark change shared tokens only. The full variant may add a short context note but cannot add messages absent from the diagram. Sequence is static by default; use motion only when a staged reveal materially explains the exchange and still follow [Motion](motion.md).
+
+## Accessibility
+
+The SVG description names actors and summarizes the message path and branch outcome. Supply an ordered message list with source, destination, kind, and label; include each guard and region outcome. Distinguish async from return with arrow-head shape and line pattern as well as text. Group related messages in DOM order and keep labels off lifelines.
+
+## 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=sequence path/to/diagram.html` to check catalog identity and registered sequence guards; use `sequence-oauth` for that specialized variant. Independently verify lifelines, participant binding, message order, markers, activations, and fragment budgets against this guide. If animated, run the motion source check and inspect the static state and controls manually. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Upward-time arrows, open heads on returns, filled heads on async sends, or activation bars that never close.
+- Branch arrows without an `alt`/`opt`/`loop` frame and guard.
+- Labels crossing a neighboring lifeline or actors arranged as swimlanes.
+- Nested `alt` blocks, more than five lifelines, or unbounded fragments.
+- Coral on both branch results, or a motion-only state that disappears in the static frame.

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

@@ -0,0 +1,65 @@
+# Slopegraph
+
+**Catalog ID:** `slopegraph`<br>
+**Parent family:** [Line and quantitative chart guidance](type-line.md)
+
+## Purpose and selection
+
+Use a slopegraph to compare several named series across exactly two comparable states: before/after, two releases, or two scenarios. The line angle communicates direction and relative change; line crossings show rank changes. Every endpoint remains labeled so the reader can recover the values.
+
+Use a line chart for three or more ordered states, a bar or dumbbell for a single-time comparison, and a scatter plot when the two endpoints use different units. A slopegraph does not reveal what happened between the endpoints; crossings are not dates or events.
+
+## Content schema
+
+Supply a dataset with:
+
+- Two state captions in chronological or explicitly named order.
+- One shared measurement name, unit, and linear numeric domain used by both vertical axes.
+- Four to ten series, each with a stable display name and a value in each state.
+- A note for excluded or missing series; do not interpolate a missing endpoint.
+- The source, period, and domain bounds needed to interpret the comparison.
+
+Each series record is `{name, from, to}`. Bind those values and endpoint labels to the same series identity in machine-readable SVG attributes so the rendered line, text, and metadata can be checked together. Round a value once and use that same value for the label and plotted coordinate.
+
+## Deterministic layout recipe
+
+1. Use a wide viewBox with a plotting region about as tall as it is wide. Place two vertical axes at fixed x positions with symmetric label gutters outside them; preserve enough room for the longest series name and the numeric value at each side.
+2. Declare one round domain `[min, max]` and one scale function `y(v) = bottom - (v - min) × plotHeight / (max - min)`. Apply the identical function to both endpoint columns. Record the domain and unit in the source line.
+3. Place each series as one straight segment from the left endpoint to the right endpoint. Draw dots at both ends. Do not add a mid-point, curve, gridline, or extra state axis.
+4. Print each series name and complete value at both ends. Put state captions below their axes and the measurement/unit in a small axis caption. Use fixed gutters; if endpoint labels collide, reduce the series count or split the comparison rather than changing coordinates.
+5. Give lines a stable ordering based on the left endpoint value. Preserve that order in the legend and source metadata. Keep labels paired to their actual endpoints even when line crossings change the order at the right side.
+
+## Visual encoding
+
+Use a restrained ink-opacity ramp for nonfocal series and one accent series chosen for the central finding, not automatically the best or worst result. Give the focal line additional weight and label it in the legend. Names and values stay in high-contrast text roles on all lines. Avoid a rainbow palette: names at both ends already identify each series. The axes and endpoint numbers carry the scale; no grid is needed.
+
+Show direction through the actual slope and the printed values. State-neutral legend wording such as “strongest tone” avoids claiming that the ramp is darker in both skins. Never suggest a rate or trajectory at an intermediate point.
+
+## Korean text
+
+Use Pretendard for service or category names; use mono for short state captions, numeric labels, units, and source metadata. Choose short paired captions such as `이전` and `이후` only when they match the actual comparison. Preserve one unit and a consistent decimal/ thousands convention at both ends. If a Hangul series name is long, wrap it in its gutter or use an agreed short label with a mapping in the legend; never slide its endpoint vertically to create room. See [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+The three skins use identical values, shared domain, coordinates, and series ordering. Only semantic colors, paper, and framing change. In the full editorial form, add a short headline, a single finding caption, and a source line that states the domain and period; keep the plot itself unchanged. Check ink opacity ramps after compositing in each skin, because their apparent lightness reverses.
+
+## Accessibility
+
+Include a title and description with the two state names, unit, domain, and main direction of change. Endpoint names and values are required redundant encodings, so color is never the sole identity cue. Keep the value labels on the correct row and maintain sufficient text and line contrast. A focal accent under 3:1 must not be the only cue; reinforce it with line weight, labels, and legend wording. Preserve legibility when printed 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=slopegraph path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify both endpoint positions from the one declared scale and compare every line, name, value, and state caption with its binding against source values and this guide; a matching ID alone does not prove those properties. Review the endpoint gutters in exported 16:9 and 4:3 layouts.
+
+## Anti-patterns
+
+- Different scales, units, origins, or transforms on the two axes.
+- Moving an endpoint or its printed value to reduce a collision.
+- Three or more states, a single series, a line colored uniquely for every series, or a crowded legend.
+- Missing values silently interpolated, unbound labels, or values omitted at either end.
+- Gridlines that repeat the endpoint values, or a curved segment that implies an unobserved path.
+- Calling a crossing a dated event or reading an intermediate value from the line.
+
+## Related references
+
+[Line chart](type-line.md) · [Scatter plot](type-scatter.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,53 @@
+# Lifecycle phase map
+
+**Catalog ID:** `state-lifecycle`<br>
+**Parent grammar:** [State machine](type-state.md)
+
+## Purpose and selection
+
+Use this state-machine specialization when one subject proceeds through a short ordered lifecycle and waits, retries, recovery, cancellation, and final outcomes are essential to the story. It keeps the progress rail separate from interruptions and terminal results. Use ordinary state machine for dense guard logic and [Sequence](type-sequence.md) when actor messages or request timing are central.
+
+## Content schema
+
+Prepare one subject, four or five primary phase states, zero to two wait/recovery states, and zero to two terminal states. Each phase has a stable id, short name, and optional short qualifier. Each transition has a source, target, event, and optional guard or action. Record cancellation and failure separately when both can happen. Mark any optional start/end pseudo-state explicitly.
+
+## Deterministic layout recipe
+
+1. Draw the primary phases in a single left-to-right rail in actual lifecycle order. Keep their centers on a common baseline and use equal box widths unless the longest label needs a wider shared size.
+2. Place wait and recovery states in a separate support band above the phase rail. Connect them to the phase where they interrupt and show the labeled re-entry edge back into the lifecycle. A retry loop names the retry limit or trigger.
+3. Place terminal outcomes in a separate band below the rail. Use separate boxes for cancelled and failed outcomes where both exist. Join each outcome to its actual transition source; do not route every phase to every terminal state unless the model says so.
+4. Add event/guard/action labels beside the corresponding edges. Keep loopbacks outside the main rail and assign distinct ports to preserve direction at crossings.
+5. Show the complete small lifecycle in one static frame: 4–5 primary phases, ≤2 support states, ≤2 terminal states, ≤9 total states, and ≤10 transitions. If either limit is reached, split the overview from detailed guard logic.
+
+## Visual encoding
+
+Position and band headings identify primary progress, waiting/recovery, and termination. Use box style and explicit tags such as `WAIT`, `RECOVERY`, and `TERMINAL` as redundant cues; use no more than two accent elements and never use color as the sole distinction. Keep event labels in a mono role and state names in the sans role.
+
+## Korean text
+
+Use short Korean names for phases and outcomes, with Pretendard and sufficient line height for multi-line Hangul. Use consistent verbs or nouns across the rail; do not mix “진행 중” labels with action sentences unless the model requires it. Use mono for event IDs, retry counts, and system terms. Keep `취소` and `실패` explicit even if they share a subdued tone. See [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+All variants preserve the same three bands, state positions, connectors, and labels. Light and dark variants alter only semantic colors. The full editorial variant may add a title, one sentence explaining the lifecycle boundary, and a source note; it should not turn the rail into a card dashboard or add steps. Keep band labels readable on both backgrounds.
+
+## Accessibility
+
+Use a title and description that name the subject, primary progression, interruption path, and terminal outcomes. Band position, text tags, and connector direction must distinguish progress from recovery without hue. Label every re-entry edge. Preserve readable node labels and distinct arrowheads after export; provide a logical reading sequence that follows the primary rail before support and terminal paths.
+
+## 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=state-lifecycle path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify band membership, counts, and labeled transition rules against source values and this guide; a matching ID alone does not prove those properties. Inspect the loopback and distinct terminal paths in every rendered skin.
+
+## Anti-patterns
+
+- Actor lifelines or request/response arrows disguised as lifecycle phases.
+- Wait states placed on the primary progress rail.
+- Cancellation and failure merged into one color-only outcome.
+- A retry loop with no labeled event or re-entry destination.
+- Every implementation-level guard copied into an overview.
+- Missing support or terminal states in the static fallback.
+
+## Related references
+
+[State machine](type-state.md) · [Sequence](type-sequence.md) · [Semantic patterns](semantic-patterns.md#9-lifecycle-phase-map) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,59 @@
+# State machine
+
+**Catalog ID:** `state`
+
+## Purpose and selection
+
+Use a state machine when a subject has a finite set of modes and legal transitions depend on events, guards, or actions. Examples include an order status, connection state, form wizard, and job queue. Use [Sequence](type-sequence.md) for messages exchanged by actors; use [Lifecycle phase map](type-state-lifecycle.md) when one subject's progress, waits, retries, cancellation, and terminal outcomes deserve distinct bands.
+
+## Content schema
+
+Prepare:
+
+- A list of distinct state records: stable id, short state name, optional qualifier, and role (`initial`, ordinary, terminal, error).
+- A list of transition records: source state, target state, triggering event, optional guard, optional action, and whether it is an entry or completion transition.
+- The subject and boundary of the state model, including any excluded subsystem or external actor.
+- One focal state, if the diagram needs emphasis.
+
+Keep labels in the compact form `event [guard] / action`; omit empty portions. Every transition must identify its trigger. Add start/end pseudo-states only where they clarify entry or completion.
+
+## Deterministic layout recipe
+
+1. Order states by the dominant progression and choose one reading direction: left-to-right for progression or top-to-bottom when the page is narrow. Place the initial point first and terminal points at the flow's far end.
+2. Lay states on a simple 4 px grid with consistent box sizes for similar label lengths. Reserve small clear corridors for loopbacks before drawing any connector.
+3. Route transitions as curves around boxes, avoiding crossings. Put short self-loops above their state. Attach loopbacks to distinct points so they do not merge into an ambiguous arrowhead.
+4. Place event/guard/action text next to the transition it names, on an opaque paper-backed label if a line passes behind it. Keep guards and actions distinct in the label sequence.
+5. Draw connectors first, then state boxes and labels. Use a filled start dot and a ringed terminal marker when pseudo-states are shown. Keep the diagram within the global 9-node and 12-transition limits; over-budget logic becomes separate diagrams.
+
+## Visual encoding
+
+Use quiet state boxes, one accent state at most, and consistent line style for all ordinary transitions. A start marker is a filled dot; a terminal marker is a ring with a center. Use the accent to point to the state the reader should notice, often an error state or successful completion. Label transitions rather than color-coding them; different outcomes need explicit text and, when necessary, different line patterns.
+
+## Korean text
+
+Use concise Korean state names in Pretendard and preserve event identifiers or code symbols in mono. Put the event first; keep guard conditions in brackets and actions after a slash. Wrap long Korean state text within the node with phrase-level line breaks. Use no color-coded “성공/실패” distinction without visible text. Follow [Korean typography](korean-typography.md) for Hangul line height and mixed text.
+
+## Light, dark, and full variants
+
+State positions, transition direction, labels, and focal state remain identical across light, dark, and full skins. Light/dark variants switch semantic token values only. The full editorial version may add one title, a concise interpretation, and a source or scope note; it must not add pseudo-states that change the model. Verify terminal rings and loopbacks at the final presentation size.
+
+## Accessibility
+
+Provide a title and description naming the subject, initial condition, principal transitions, and terminal outcomes. Every transition has a readable event label; do not encode legality by color alone. Keep arrowheads separate from box borders, preserve connector contrast, and ensure start and terminal symbols differ by both shape and label. A screen-reader description should follow the flow order rather than list states alphabetically.
+
+## 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=state path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify state/transition structure, limits, and required labels against source values and this guide; a matching ID alone does not prove those properties. Inspect branch density and labels in rendered light, dark, and full variants; structural checks do not decide whether a transition is understandable.
+
+## Anti-patterns
+
+- Unlabeled transitions or arrows whose direction is unclear.
+- More than twice as many transitions as states without splitting the model.
+- A separate “timeout” edge from every state when one shared rule can be stated once.
+- Lifelines and actor-to-actor messages, which belong in Sequence.
+- A wait/retry lifecycle squeezed into the same rail as the main phases.
+- A focal state indicated only by hue, or connectors hidden behind boxes and labels.
+
+## Related references
+
+[Lifecycle phase map](type-state-lifecycle.md) · [Sequence](type-sequence.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,52 @@
+# Story map
+
+**Catalog ID:** `story-map`
+
+## Purpose and selection
+
+Use a story map to show one persona's end-to-end narrative and how user-visible stories are sliced into releases. The release cut is required: without it, the figure is a backlog grid rather than a planning map. Use Kanban for work state, a user journey for stages and sentiment, and a timeline for dated milestones.
+
+## Content schema
+
+Provide one persona, up to five ordered activities, one or two walking-skeleton user steps under each activity, and up to three release slices. Each story card describes a user-visible outcome and belongs to one activity and one slice. Identify the single highest-risk story. Include a release cut after the first slice and a short source/context note.
+
+## Deterministic layout recipe
+
+1. Lay out activity headers from left to right in the persona's narrative order. Use a consistent 200 px card width, 24 px gutters, and equal baselines; avoid ordering by priority.
+2. Directly below, align each activity's user steps on one walking-skeleton row. Use 32 px step cards and reserve two step slots per activity so the row stays level when an activity has only one step.
+3. Add release bands underneath and label them in a fixed 96 px left margin. Use 48 px story cards and place each in its activity column. Use a subtle vertical column rule wherever a release row has gaps so empty space still reads as part of that activity.
+4. Draw one horizontal release-cut rule immediately after the first slice and label it `RELEASE CUT`. Use it as accent target one. Give only the highest-risk story card the second accent treatment and an explicit `RISK` tag.
+5. Finish with a compact legend and a source/context line. Keep the entire map within five activities, three slices, twelve story cards total, and four cards per slice. Collapse the long tail into a named “Later” slice or split the map by persona when needed.
+
+## Visual encoding
+
+Backbone cards are wider than story cards; steps form the thin row between them. Release bands use low-contrast backgrounds or hairlines, and the release cut is a strong rule. Card text, activity-column position, and row label carry meaning. Use exactly two accent targets: the release cut and the single highest-risk story card; its `RISK` tag belongs to that same cue. Stories describe user outcomes rather than implementation chores. Slice names describe scope (`MVP`, `Next`, `Later`) rather than dates that can slip.
+
+## Korean text
+
+Use short Korean activity and story phrases written from one persona's perspective, with Pretendard. Keep each story outcome concrete and user-visible. Use the same vocabulary for activity names across the backbone and related documents. If ticket IDs or estimates appear, render them in mono and preserve them exactly. Prefer outcome-based slice labels such as `첫 출시`, `다음`, `이후`; follow [Korean typography](korean-typography.md) for spacing and line breaks.
+
+## Light, dark, and full variants
+
+The map's column order, story placement, and cut position are identical in light, dark, and full variants. Switch semantic tokens for light/dark and confirm the release rule remains visible. The full variant may add a title, a brief takeaway, and a source note around the same map; it does not add a card grid or change the release cut.
+
+## Accessibility
+
+Add a title and description that state the persona, narrative direction, slices, and location of the release cut. Label all activity columns and release rows. The cut remains identifiable by both a line and text; risk uses a tag and border as well as color. Maintain readable contrast on band fills and ensure the row/column relationship is apparent without relying on card 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=story-map path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify activity/slice/card caps, alignment, release-cut presence, and accent budget against source values and this guide; a matching ID alone does not prove those properties. Review at PPTX and DOCX target dimensions; small cards that pass the layout check may still need shorter text.
+
+## Anti-patterns
+
+- No release cut, more than three slices, or date-named slices standing in for scope.
+- Activities ordered by priority instead of narrative sequence.
+- Stories that describe internal refactoring rather than a user outcome.
+- Multiple personas, Kanban state columns, or a sentiment curve in one map.
+- Cards floating without an activity column when a slice has gaps.
+- More than two accent targets or a release cut encoded by color alone.
+
+## Related references
+
+[Kanban](type-kanban.md) · [User journey](type-journey.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,53 @@
+# Streamgraph
+
+**Catalog ID:** `streamgraph`<br>
+**Parent family:** [Line and quantitative chart guidance](type-line.md)
+
+## Purpose and selection
+
+Use a streamgraph to show how a nonnegative total and its composition change across many evenly spaced periods. The outer envelope shows total volume; the layers show each component's share. Use a bar chart or table when exact per-period values matter, a line chart for a few trend points, and a 100% stacked area when only proportions matter.
+
+## Content schema
+
+Supply 3–24 ordered periods and 2–6 named layers. Each layer has one nonnegative numeric value for every period, one stable display name, and a declared unit. Keep zero periods in the dataset. Provide a shared scale, the total for each period, and the source/date context. If data is illustrative, say so. Layer names contain no digits so the legend's numeric total remains unambiguous.
+
+## Deterministic layout recipe
+
+1. Fix the plot rectangle and period positions evenly from left to right. Use a symmetric baseline at its vertical center. At each period, sum all layer values and multiply by the one shared linear scale. Set the stack top to `baseline − totalHeight/2` and the bottom to `baseline + totalHeight/2`.
+2. Choose one fixed stack order for the entire chart. Put the largest aggregate layers nearest the center line and keep that order at every period; order changes would make a band's identity jump.
+3. For each period, accumulate layer thicknesses from the lower boundary. Use the same scale for every layer and period. Preserve a true zero as a zero-thickness pinch; do not interpolate or drop it.
+4. Draw boundaries as smooth curves whose control points preserve the true period vertices. If using the canonical smoothing recipe, keep control points at one-sixth of the chord; never shift vertices to make the silhouette smoother. Add a thin paper-colored separator between neighboring fills.
+5. Omit y-axis ticks and gridlines. Label periods below the plot, and put each layer's name and total in the legend. Mark at most one landmark period with a short leader and mono label. Include the shared scale or bucket size in a source line.
+
+## Visual encoding
+
+Use one restrained ink-opacity ramp for nonfocal layers and one accent layer selected for the point of the story. The largest aggregate layer receives the strongest neutral tone; the accent does not automatically mean the largest. The envelope height encodes total volume; layer thickness encodes amount. Do not use a 100% normalization or private scale per layer. Use skin-neutral legend language such as “strongest tone.”
+
+## Korean text
+
+Use Pretendard for layer names and period captions; use mono for totals, dates, units, and source metadata. Keep the same unit across all layers and spell it once in the axis/source line. Prefer short names without digits; if a Korean service identifier inherently includes a numeral, provide a separate short label that contains no additional number in the legend while retaining the true identifier in metadata. Follow [Korean typography](korean-typography.md) for number formatting and Hangul line height.
+
+## Light, dark, and full variants
+
+Keep the dataset, layer order, stack geometry, scale, and landmark the same in all variants. Light and dark skins resolve the same ink opacities against their own paper token; check separator visibility and layer distinction after rendering. A full editorial layout may add a finding headline, a short caption, and a source note around the same plot. Do not add text inside layer shapes.
+
+## Accessibility
+
+Provide a description that states the periods, unit, shared symmetric baseline, total trend, and focal layer. Name every layer in the legend and report its aggregate total. Since adjacent fill tones may be close, labels and legend order must identify each layer; hue cannot be the only cue. Avoid text over fills and confirm separators are visible in both skins and 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=streamgraph path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify each stack boundary, fixed order, shared scale, symmetric envelope, period/layer caps, zero handling, and legend bindings from declared data against source values and this guide; a matching ID alone does not prove those properties. Inspect the smallest layer and zero pinch at presentation size.
+
+## Anti-patterns
+
+- A shifting baseline, bottom-anchored stack, or independently normalized layer.
+- Uneven period spacing where periods are equally spaced, or changing stack order.
+- Dropping zero periods, smoothing away real vertices, or reading exact values off the envelope.
+- Too many layers for the palette or text placed on colored areas.
+- A legend that describes opacity by a lightness direction that reverses between skins.
+- Multiple landmark callouts that compete with the overall silhouette.
+
+## Related references
+
+[Line chart](type-line.md) · [Bar chart](type-bar.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,52 @@
+# Swimlane
+
+**Catalog ID:** `swimlane`
+
+## Purpose and selection
+
+Use swimlanes for a cross-functional process whose key question is who owns each step and where work crosses between people, teams, or systems. Choose horizontal lanes for a left-to-right process or vertical lanes for a top-to-bottom one. Use Sequence when messages and timing between technical actors are the subject; use a flowchart for decision logic with no ownership axis.
+
+## Content schema
+
+Prepare a list of up to five named lanes, each with a stable owner id and optional role. List ordered process steps with a short action, owning lane, and optional duration or condition. Record directed handoffs from one step to the next, including branch outcomes and the lane boundary crossed. Declare the process start/end and whether any step is an external dependency.
+
+## Deterministic layout recipe
+
+1. Order lanes by the real workflow, not by alphabet or team hierarchy. Allocate equal lane widths/heights and label them in a fixed margin or header band.
+2. Place process steps in chronological order along one shared axis. Each step belongs to exactly one lane and remains fully inside it. Use similarly sized cards for similar actions; allow a lane with one step to keep its empty space.
+3. Draw lane dividers as quiet hairlines. Route ordinary progression mostly straight; route handoffs through short orthogonal turns with clear arrowheads. Give each handoff a visible exit and entry point on its lane boundary.
+4. Reorder steps when their order is flexible to reduce back-and-forth connector crossings. Keep genuine returns and branches explicit; do not disguise a loop as a normal handoff.
+5. Limit the figure to five lanes, nine steps, and twelve arrows under the global diagram budget. Split parallel teams or subprocesses into a second view when the crossings obscure ownership.
+
+## Visual encoding
+
+Lane headings carry ownership; node placement carries responsibility; arrows carry sequence and handoff. Use a single accent for the handoff with the greatest cost, risk, or latency, and label that reason in a callout or legend. Do not color every lane differently: lane position and heading already encode owner. Decision outcomes require text and visibly distinct branches.
+
+## Korean text
+
+Use Pretendard for lane names and action labels. Keep action wording short and consistent, for example verb-first steps in Korean. Use mono only for system identifiers, time codes, and ticket references. Keep step labels inside their lane without splitting a compound name at an awkward syllable boundary. Follow [Korean typography](korean-typography.md) for line breaks and mixed script.
+
+## Light, dark, and full variants
+
+Lane order, task positions, and handoff routing remain fixed across light, dark, and full variants. Change only semantic tokens between light and dark; verify the lane dividers still separate areas without dominating the process. A full editorial version can add a concise process title, one summary of the costly handoff, and a source or scope note; no additional lanes are implied by decorative framing.
+
+## Accessibility
+
+Include a title and description that name the process, lane owners, direction of progression, and any consequential handoff. Make lane headers visible in text and keep every step wholly within its owner's lane. Handoff arrows should cross boundaries clearly and include arrowheads; color is supplemental. Provide an ordered textual summary for screen readers and check that connector direction survives grayscale export.
+
+## 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=swimlane path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify lane count, step ownership, and handoff geometry against source values and this guide; a matching ID alone does not prove those properties. Inspect lane crossings in both wide and portrait exports; verify that any sideways scrolling stays inside the diagram container.
+
+## Anti-patterns
+
+- An unlabeled lane or an action card straddling two owners.
+- Too many colored lanes with no corresponding semantic distinction.
+- Repeated back-and-forth crossings caused by a poor step order.
+- Message-level protocol details that belong in Sequence.
+- Handoffs indicated by proximity or color without a directed connector.
+- A legend that calls attention to the accent but does not name its meaning.
+
+## Related references
+
+[Sequence](type-sequence.md) · [Flowchart](type-flowchart.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)

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

@@ -0,0 +1,52 @@
+# Timeline
+
+**Catalog ID:** `timeline`
+
+## Purpose and selection
+
+Use a timeline for events whose position on a real or declared time scale is the main point: release history, incidents, milestones, or a roadmap of dated events. Use Gantt for task durations and dependencies, and use Swimlane when ownership and handoffs matter more than elapsed time.
+
+## Content schema
+
+Each event needs a stable id, label, exact date/time or honest date interval, optional owner/category, and source. Declare the time zone and granularity when relevant. Mark which event is editorially focal. If a date is approximate, preserve the uncertainty as a range or explicit qualifier instead of inventing a day.
+
+## Deterministic layout recipe
+
+1. Declare the time domain `[t0, t1]`, scale, and tick interval. Map each exact event time with `x(t) = plotLeft + (t − t0) × plotWidth / (t1 − t0)`. Unequal elapsed intervals therefore receive unequal spacing.
+2. Draw one quiet horizontal baseline and ticks at meaningful calendar boundaries. Put date labels below the baseline in chronological order.
+3. Place an event mark at its mapped x coordinate. Alternate event labels above and below the line and connect each label with a short hairline. For dense events, use a visible axis break, widen the plot, or split the time range; do not compress dates invisibly.
+4. Draw a major milestone with a slightly larger mark and the single accent treatment. For a true interval, use a span with both endpoints or a band and label the interval; do not represent duration with an event dot.
+5. Keep the timeline to a readable number of events. When the time unit changes, use separate clearly labeled panels rather than mixing scales on one baseline.
+
+## Visual encoding
+
+Position alone encodes time. Size and accent may mark editorial importance, never event duration. Use explicit text for event category, milestone status, or uncertainty. Draw axis breaks when a discontinuity changes the spacing. Avoid decorative icons unless they add a stable category cue with a text equivalent.
+
+## Korean text
+
+Use Pretendard for event labels and mono for dates, time codes, and source markers. Keep one date format throughout the figure; state the timezone where an hour could be ambiguous. Korean date labels such as `2026년 9월` should not be compressed into a slash form with an unstated locale. Put uncertainty in visible Korean text (`약`, `전후`, `범위`) or show an interval. Follow [Korean typography](korean-typography.md) for numerals and mixed text.
+
+## Light, dark, and full variants
+
+All variants retain exact event positions, tick intervals, and interval widths. Light and dark variants change semantic tokens only. The full editorial layout may add a title, a short time-range summary, and a source line; it must preserve the original temporal scale. Check the baseline and focal mark in grayscale and in both skins.
+
+## Accessibility
+
+Provide a title and description with the date range, scale, event order, and any uncertainty or axis break. Label ticks with units. Alternate label placement to reduce collision but preserve each label-to-event leader. Milestone status must be named in text as well as shown with an accent mark. Ensure markers and rules contrast against the paper.
+
+## 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=timeline path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify monotonic event placement, time-to-x consistency, declared intervals, and axis breaks against source values and this guide; a matching ID alone does not prove those properties. Inspect the densest part of the timeline at the actual presentation width.
+
+## Anti-patterns
+
+- Equal spacing for events with unequal elapsed time.
+- A missing time unit, timezone, range qualifier, or visible axis break.
+- A dot used for an event with a meaningful duration.
+- Labels colliding over the baseline or detached from their events.
+- Using icon shape or color alone to identify milestone category.
+- Reordering events to make the layout look balanced.
+
+## Related references
+
+[Gantt](type-gantt.md) · [Swimlane](type-swimlane.md) · [Style guide](style-guide.md) · [Output spec](output-spec.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Export](export.md)