@litfamily/lithermes 1.0.7 → 1.0.9

package/assets/lithermes-plugin/skills/lit-diagram-drawer/references/type-tree-block-decomposition.md

@@ -0,0 +1,57 @@
+# Traceable block decomposition
+
+**Catalog ID:** `tree-block-decomposition`<br>
+**Parent grammar:** [Tree / hierarchy](type-tree.md)
+
+## Purpose and selection
+
+Use this semantic pattern when a system must be decomposed into individually addressable blocks that readers can cite and trace to implementation. Each block remains a noun-like structural element. The hierarchy shows parentage; metadata carries the fuller block record. Use a process type for actions, a dependency graph for cross-block relationships, and Architecture for a small set of runtime zones.
+
+This is a SysML-informed documentation pattern, not a claim of SysML, IDEF0, XMI, or tool-certified conformance.
+
+## Content schema
+
+Every node needs a stable hierarchical id (for example, `PAY-001-02`), noun-phrase name, and implementation path. Every nonroot node also has a parent id. Its complete record contains inputs, outputs, constraints, assumptions, and implementation reference. An optional short input/output pair may appear as the node sublabel only when both fit without crowding. Keep longer values in a sidecar block registry beside the editable source; the visual tree is not the full record.
+
+The SVG node's metadata binds `data-block-id`, `data-block-parent`, and `data-block-name`, plus concise `data-block-input`, `data-block-output`, `data-block-constraint`, `data-block-assumption`, and `data-block-impl` fields when supplied. The visible id badge must exactly match its metadata. When the user asks for structured traceability data, export an opt-in `<diagram-basename>.registry.json` sidecar with a `source` basename and a `blocks` array in source-document order. Project only values already present in the `data-block-*` attributes; omit absent fields and the root's parent key. Do not infer or supplement records, and do not generate the registry by default. Do not put credentials, private source excerpts, or sensitive implementation details in an exported diagram.
+
+## Deterministic layout recipe
+
+1. Follow the Tree layout: root above its children, with short vertical stem, orthogonal sibling bus, and drops into child boxes. Keep a stable sibling order and one parent for every nonroot block.
+2. Place the id badge as a compact tag inside the node box. Put the block name in the normal name slot. A short I/O qualifier may occupy the existing sublabel line; it never becomes a separate connector label.
+3. Snap tree geometry to the layout grid. Keep the root-plus-three-tier maximum and five-per-level ceiling, with the stricter global maximum of nine nodes. Split at subsystem boundaries and preserve stable ids between diagrams when the hierarchy is larger.
+4. Draw connectors before boxes. Do not add I/O arrows between siblings or cousins; that changes the layout into a dependency graph. Avoid visible constraints or assumptions that would turn a compact map into a specification wall.
+5. Verify that the registry contains every block and that each visible badge, node, metadata record, and implementation reference resolves to the same stable id.
+
+## Visual encoding
+
+The tree owns the connector grammar and layout. This pattern adds only the id badge and optional brief ports; it adds no new line styles, status colors, or edge labels. Keep IDs in mono and structural names in Pretendard. The accent budget remains at most two elements, but a traceability tree normally needs no focal color.
+
+## Korean text
+
+Use concise Korean noun phrases for block names; names identify structures, not actions. Preserve stable Latin ids, paths, file names, and technical tokens exactly, using mono. Write registry descriptions in Korean or English consistently and avoid mixing language in the same badge. Keep I/O phrases short and line-broken at phrase boundaries. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+Keep all node positions, ids, hierarchy, and registry bindings identical across light, dark, and full variants. Light and dark change semantic tokens only. The full editorial form can add scope and provenance around the tree; it must not replace the stable id with a decorative label. Check id badge contrast at the final export size.
+
+## Accessibility
+
+Provide a title and description explaining the root block, hierarchy direction, and how to locate the registry. Each block has a visible id and name; color is not an identifier. Describe hierarchy in parent-first order. The exported SVG must preserve accessible title/description and metadata, and a table or registry must remain available for the full record.
+
+## 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=tree-block-decomposition path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify node ids, parent ids, visible badges, metadata fields, hierarchy budgets, and orthogonal edges against source values and this guide; a matching ID alone does not prove those properties. When a registry was explicitly requested, compare its ordered projection with the source attributes and check for duplicate ids, unresolved parents, and cycles. Inspect a sample registry lookup against the saved SVG/PDF/PNG package.
+
+## Anti-patterns
+
+- Verb-phrase nodes that describe work rather than structural components.
+- Separate ICOM sides, input/output arrows, or connector-adjacent identifiers.
+- An id badge that disagrees with node metadata or is absent from the registry.
+- Long constraints and assumptions rendered as tiny in-node paragraphs.
+- A tree used to imply cross-block data flow or multi-parent dependencies.
+- Calling the result standards-compliant because it borrows block terminology.
+
+## Related references
+
+[Tree](type-tree.md) · [Semantic patterns](semantic-patterns.md#8-traceable-block-decomposition) · [Output spec](output-spec.md) · [Export](export.md) · [Accessibility](accessibility.md) · [Korean typography](korean-typography.md) · [Verifier guide](verifier-guide.md) · [Office export](office-pptx-docx.md) · [Style guide](style-guide.md)

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

@@ -0,0 +1,54 @@
+# Tree / hierarchy
+
+**Catalog ID:** `tree`
+
+## Purpose and selection
+
+Use a tree for a strict parent-to-children hierarchy: taxonomy, file structure, decision breakdown, or bounded system decomposition. Each nonroot node has one parent and the hierarchy contains no cycles. Use a dependency graph when nodes can have several parents, cross-links, or cycles; use Nested for containment where branch relationships do not need tracing.
+
+For stable block identifiers and per-block inputs, outputs, constraints, and implementation traceability, load [Traceable block decomposition](type-tree-block-decomposition.md) and [Semantic patterns](semantic-patterns.md#8-traceable-block-decomposition).
+
+## Content schema
+
+Each node carries a stable id, parent id (empty only for the root), short name, optional one-line qualifier, and optional focal flag. Each edge is implied by the parent relation; do not add independent edge labels. Record the intended reading direction, depth, and children per level before placing nodes.
+
+## Deterministic layout recipe
+
+1. Place the root at the top and children on the next row; use equal row pitch for each depth. A left-to-right orientation may be used for a very wide or heavily labeled tree, but select one orientation for the whole figure.
+2. Center each parent above the span occupied by its descendants. Order siblings by the domain's actual sequence; if none exists, use a stable declared order so reruns are reproducible.
+3. Route orthogonal connectors: short parent stem, horizontal sibling bus, then a short drop to each child. Keep connectors behind nodes and attach them at the center of node edges.
+4. Use two node widths at most, based on measured label lengths. Align boxes to the layout grid; use a lighter border or fill for leaves only when it remains a redundant cue.
+5. Keep at most nine nodes, four levels including the root, and five children at a level. Beyond the budget, split at a meaningful subsystem boundary and provide cross-reference ids between figures.
+
+## Visual encoding
+
+Connector topology carries the hierarchy; box position and text carry identity. Use a single accent node at most, chosen as root or a critical leaf. Do not style every level as a different color. Use the same visual weight for siblings and the same depth spacing throughout. Place connectors before cards so their paths terminate cleanly at the box edge.
+
+## Korean text
+
+Use Pretendard for node names and qualifiers, with compact noun phrases that preserve parent-child meaning. Keep IDs, file paths, and version strings in mono. Wrap labels at natural phrase boundaries and size nodes from the longest Korean label in that row. Do not omit an intermediate hierarchy term to save space. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+Keep node coordinates, sibling order, and connectors identical across the three skins. Switch semantic stroke and fill tokens between light and dark. In the full editorial variant, add a short title, scope note, or takeaway outside the hierarchy; do not introduce a separate card grid or imply extra nodes. Confirm orthogonal connectors remain distinguishable on dark paper.
+
+## Accessibility
+
+Use a title and description that state the root, hierarchy direction, and scope. The logical reading order follows each parent before its children and proceeds in the declared sibling order. Preserve branch structure without color. Ensure connector-to-box joins are visible, labels meet contrast requirements, and overflow is not hidden behind a crop.
+
+## 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=tree path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify one root, valid parent links, acyclicity, depth/branch/node budgets, and orthogonal connector joins against source values and this guide; a matching ID alone does not prove those properties. Inspect the densest level in the rendered full-width export.
+
+## Anti-patterns
+
+- A node with two parents, a cycle, or an unlabeled skipped level.
+- Diagonal connectors or connectors that stop short of a child.
+- More than four levels, inconsistent box widths, or one exceptionally broad row.
+- Highlighting the root and a leaf with competing accents.
+- Cross-tree dependencies drawn as if they were parent-child links.
+- Cropping a large tree so that its root or branch context disappears.
+
+## Related references
+
+[Traceable block decomposition](type-tree-block-decomposition.md) · [Dependency graph](type-dependency.md) · [Semantic patterns](semantic-patterns.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-treemap.md

@@ -0,0 +1,54 @@
+# Treemap
+
+**Catalog ID:** `treemap`
+
+## Purpose and selection
+
+Use a treemap when the relative size of parts within a whole is the central message: storage use, budget, market share, population, or time allocation. Area carries the quantitative comparison. Use a bar chart when exact rank and values matter more than part-to-whole composition, Nested for nonquantitative containment, and Tree when parent-child tracing is the goal.
+
+The two-dimensional [Marimekko variant](type-marimekko.md) has its own catalog route; use it only when both category share and within-category composition matter. See [Bar chart](type-bar.md) for adjacent comparison choices.
+
+## Content schema
+
+Provide one total, 4–8 nonnegative cells, a stable cell id/name, optional parent id for a two-level hierarchy, a value, and its percentage of the declared whole. Include source, unit, period, rounding policy, and an explicit “Other” definition whenever small categories are aggregated. Each cell binds its computed share in `data-share`, including cells with no visible text. A focal cell may be selected for annotation; it is not necessarily the largest.
+
+## Deterministic layout recipe
+
+1. Fix a plot rectangle and calculate each exact share from the unrounded source values. Confirm the shares reconcile to the whole before arranging cells.
+2. For a two-level hierarchy, partition the parent rectangles first, then lay out each parent's children within its rectangle. Sort siblings by descending share, then by stable id for ties. Use a squarified tiling: append the next item to the current row only while it improves that row's worst aspect ratio; lay each row along the shorter side of the remaining rectangle. Use this tie-break consistently so identical data yields identical geometry. Do not exceed two levels in a static diagram.
+3. Snap cell edges to the 4 px layout grid and leave equal 4 px gutters. Recalculate resulting areas after snapping; keep relative area error within the verifier's published tolerance, checking the smallest cell most closely. Do not stretch or shrink one cell to make labels fit.
+4. Label tiers are based on actual text measurement: large cells can hold name, value, and share; medium cells name and value; small cells only a compact abbreviation when it fits; slivers carry no text. A cell at least 12×12 px may contain a centered information mark if it stays inside the boundary; smaller slivers are identified by their legend entry and stable position.
+5. Give every cell an appropriate legend entry. If a category cannot be drawn faithfully or remains invisible at the target size, merge it into a named “Other” rather than silently dropping it. Include a source line that states the area encoding, dataset, and date.
+
+## Visual encoding
+
+Area is the data encoding. Use a restrained ink-opacity ramp for neutral cells and one accent cell at most, with accent stroke as a focal cue. Do not use a rainbow, gradient, 3-D, or shadow. State the measure in the source line (for example `AREA = POPULATION`). Name the ramp by contrast strength, not “darker/lighter,” because its apparent lightness changes with the skin. Keep cell labels on the paper-safe label layer and use a mask where patterned backgrounds could show through.
+
+## Korean text
+
+Use Pretendard for cell names and mono for exact values, shares, and source notes. Keep the same unit and decimal precision across all cells; use one Korean thousands and decimal convention. Preserve official category names, and use a legend mapping when an abbreviation is necessary. Avoid rotated Korean text. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+All variants use the exact same shares, geometry, label tiers, and focal cell. Light and dark skins change semantic tokens, not opacity values or area. Recheck text contrast against each composited cell fill; midtone fills behind small text are not acceptable. A full editorial layout may add a title, one interpretation sentence, a source line, and a short legend outside the plot without changing cell sizes.
+
+## Accessibility
+
+Provide a title and description stating what area encodes, the whole, the leading components, and how “Other” is composed. Name every cell in an adjacent legend/table, including unlabeled slivers. Color reinforces the area only; the accent does not define ranking. Ensure the information mark, if used, stays inside its cell and that names and values meet text contrast. Supply the exact source data as a text alternative for audit or reuse.
+
+## 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=treemap path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify `data-share` against drawn area, validate whole reconciliation, layout budgets, relative error, marker containment, and text bindings against source values and this guide; a matching ID alone does not prove those properties. Inspect the smallest cell and the ramp in both rendered skins.
+
+## Anti-patterns
+
+- Stripe tiling, uneven gutters, or layout changes that cannot be reproduced from the same input.
+- Missing or fabricated cells, or a total contradicted by displayed rounded values.
+- Treating area as an exact share after snapping without checking relative error.
+- Rotated or tiny text used to rescue an undersized cell.
+- Rainbow colors, dark/light legend language, shadows, or using accent to imply largest.
+- A sliver with no legend entry or metadata share.
+
+## Related references
+
+[Bar chart](type-bar.md) · [Nested](type-nested.md) · [Tree](type-tree.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-uml-class.md

@@ -0,0 +1,52 @@
+# UML class diagram
+
+**Catalog ID:** `uml-class`
+
+## Purpose and selection
+
+Use this diagram for static object structure when operations, inheritance, composition, or typed class relationships matter. Use an ER diagram for entities, attributes, and cardinality; use Sequence, State, Swimlane, or Architecture for the corresponding UML behavior, state, activity, or deployment views. This guide covers class-diagram grammar only.
+
+## Content schema
+
+Prepare up to seven classes, each with a name, optional `interface` stereotype or abstract marker, selected attributes, and meaningful operations. Each member includes visibility, name, and type/signature. Prepare up to eight relationships from the defined vocabulary: inheritance, realization, composition, aggregation, association, or dependency. Association endpoints state multiplicity. Choose one focal class and list all six relationship kinds in a compact legend so the notation is unambiguous.
+
+## Deterministic layout recipe
+
+1. Group classes by package or domain role, then place the focal/base type centrally with subclasses or implementers nearby. Prefer straight links or one orthogonal elbow per relationship. Split by package when routes cross repeatedly.
+2. Draw each class as one content-sized box with up to three compartments: centered name, attributes, operations. Omit empty compartments rather than padding boxes to equal height. Keep each member on one line; overflow beyond five members in a compartment becomes an explicit ellipsis or a separate detail view.
+3. Draw connectors before boxes using orthogonal routes with rounded elbows. Use fan-out attach points separated enough to distinguish parallel relationships. Keep labels on opaque paper masks with clear space around the line.
+4. Place multiplicities close to association endpoints on both sides. Put the composition or aggregation diamond at the owner end. Define every marker in the SVG and include all six notations in the legend, even when some are unused.
+5. Keep to seven classes, eight relationships, five members per compartment, and two accent elements. Four or five classes is the normal target; split dense packages instead of shrinking text.
+
+## Visual encoding
+
+Use a stable, explicit line and endpoint vocabulary: inheritance uses a solid hollow triangle; realization uses a dashed hollow triangle; composition has a filled ownership diamond; aggregation has a hollow ownership diamond; association uses an open arrowhead and multiplicities; dependency uses a dashed open arrow. Do not swap composition and aggregation. Use accent for the focal class and, as one grouped cue, its inbound inheritance/realization edges. Keep member visibility symbols and signatures in mono.
+
+## Korean text
+
+Use Pretendard for class names and short stereotypes; use mono for typed attributes, method signatures, visibility signs, and multiplicities. Preserve source-language identifiers verbatim when they are code symbols; explain them in a concise Korean caption if needed. Avoid breaking method signatures across lines. Follow [Korean typography](korean-typography.md) for Hangul line height and mixed names.
+
+## Light, dark, and full variants
+
+Class positions, compartments, relationship types, and multiplicities must match across the three skins. Use the paper token for hollow marker interiors and semantic line tokens for outlines. The full editorial form may add package framing and a short explanation of the focal class; it must not add decorative class boxes or imply unlisted members. Check every marker against the background after export.
+
+## Accessibility
+
+Supply a title and description naming the domain, focal class, and most important relationships. Keep line style and arrowhead shape redundant with legend text; line color alone must never distinguish relationship types. Ensure multiplicities and members remain readable, and ensure an SVG reader can access class names and relation labels in a sensible order.
+
+## 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=uml-class path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify class/member caps, marker vocabulary, relationship direction, multiplicities, and connector joins against source values and this guide; a matching ID alone does not prove those properties. Inspect dense elbow crossings and all six legend keys at presentation size.
+
+## Anti-patterns
+
+- Listing every getter, setter, or implementation detail instead of the members needed to explain the model.
+- Using class boxes when the story is entity fields and cardinalities.
+- Composition and aggregation used as synonyms, or association without endpoint multiplicities.
+- Diagonal connectors, omitted legend markers, or unlabeled stereotype symbols.
+- Equal-height boxes with large empty compartments.
+- Accent on several unrelated classes or relationship kinds.
+
+## Related references
+
+[ER diagram](type-er.md) · [Sequence](type-sequence.md) · [State machine](type-state.md) · [Architecture](type-architecture.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-venn.md

@@ -0,0 +1,51 @@
+# Venn diagram
+
+**Catalog ID:** `venn`
+
+## Purpose and selection
+
+Use a Venn diagram to explain meaningful overlap between two or three named sets: shared traits, eligibility groups, or a conceptual intersection. Use a matrix for four or more sets, or a table when exact membership matters more than the overlapping shape. Do not use circle area as a quantitative claim unless the source membership counts and geometry were deliberately computed and verified.
+
+## Content schema
+
+Define two or three sets with stable ids, names, optional short descriptions, and their membership records. For every region (each set-only area and every intersection), provide the intended label or explicitly mark it empty. State whether circles are conceptual or quantitatively sized. If an intersection is the focal point, name it in the brief rather than choosing one after rendering.
+
+## Deterministic layout recipe
+
+1. Use two circles for one pairwise comparison or three circles for a three-way overlap. Assign centers and radii on the 4 px grid. Use equal radii for comparable conceptual sets; vary radii only when the intended relative set sizes are supported by source data.
+2. Arrange circles symmetrically around the intended common area, leaving clear outer label positions. Verify that every required intersection exists and is large enough to hold its label. Do not distort a circle to make text fit.
+3. Put each set name outside its circle with enough clearance from the stroke. Put region labels in the open area they describe. If an overlap is too small, use a short leader to a label in clear space and keep the connection unambiguous.
+4. Use low-opacity fills so overlaps remain visible. Highlight one intersection with a restrained accent fill or outline, never both every region and all circles. Add a simple legend only when the membership encoding needs explanation.
+
+## Visual encoding
+
+Circle boundaries identify sets; geometric overlap identifies shared membership. Use soft, related fills and clear hairline borders. Do not make a third set appear as a new color alone; label it. If the numbers of members are not encoded faithfully by circle and intersection areas, state that the diagram is conceptual and provide exact counts in an adjacent table or text.
+
+## Korean text
+
+Use Pretendard for set names and intersection labels. Keep labels concise and name the shared property explicitly. Do not let Hangul labels cross circle borders; use phrase-level wrapping or a leader to a clean label position. Use mono only for exact counts or source identifiers. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+Centers, radii, overlaps, and label placement remain identical in light, dark, and full variants. Change semantic surface/fill tokens only and verify compounded overlaps remain distinguishable. In the full version, a concise title and short explanation can sit outside the set geometry; never add decorative circles that look like extra sets.
+
+## Accessibility
+
+Include a title and description that name every set and explain each relevant overlap. Give each circle a visible set name. Text or line style must reinforce any highlighted intersection; color alone does not define membership. Provide the exact set membership or counts in a text alternative when the shape is quantitative.
+
+## 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=venn path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify two/three-set limits, circle geometry, required membership regions, and label placement against source values and this guide; a matching ID alone does not prove those properties. Inspect overlap regions in both skins and at the target Office size.
+
+## Anti-patterns
+
+- Four or more circles crowded into one page.
+- Missing set names or unexplained empty/intersection regions.
+- Circles that do not overlap when intersection is the point.
+- Label text touching a circle stroke or floating without a region association.
+- Quantitative area claims made by a conceptual sketch.
+- Accent color on several overlaps so no one region is focal.
+
+## Related references
+
+[Nested](type-nested.md) · [Treemap](type-treemap.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-wardley.md

@@ -0,0 +1,52 @@
+# Wardley map
+
+**Catalog ID:** `wardley`
+
+## Purpose and selection
+
+Use a Wardley map to reason about a value chain against component evolution: what is user-visible, what is a dependency, and what is moving toward commoditization. It is a strategy map, not a runtime architecture. Use Architecture for deployed components and connections, or a dependency graph when graph topology is the primary story.
+
+## Content schema
+
+Each component needs a stable id, short name, value-chain position, evolution band, and its dependency links. Record which components are moving, their rightward destination or time horizon, and the evidence behind the placement. Use up to nine components, twelve links, and two movement arrows. Each component must take part in the value chain through at least one incoming or outgoing dependency.
+
+## Deterministic layout recipe
+
+1. Fix a two-axis plot. The horizontal axis has four qualitative bands in order: Genesis, Custom-built, Product, Commodity. The vertical axis runs from more visible to the user at top to invisible at bottom. Add no numeric tick values.
+2. Place each component inside the appropriate evolution band and value-chain level. For repeatability, use an agreed sub-band position (early/middle/late) and a stable vertical order derived from the chain. Record the placement rationale in the source or companion notes.
+3. Draw dependency links as thin straight lines without arrowheads; this is the deliberate exception to the shared orthogonal-connector default because the coordinates are map data. Position represents evolution and visibility. Label dependencies only when the source data needs a qualifier. Avoid bending a line into another semantic type.
+4. For a moving component, draw one short right-pointing dashed accent arrow toward the next evolution band. Keep it clear of nearby dependency lines and component labels; add an on-arrow note only for a meaningful time horizon or driver.
+5. Add a compact legend for component, dependency, and movement. Keep axis captions horizontal; stack short “visible to user”/“invisible” labels beside the y-axis rather than rotating text.
+
+## Visual encoding
+
+Band position encodes qualitative evolution; vertical position encodes value-chain visibility; links encode dependency; a dashed right-pointing arrow encodes movement toward commodity. Use plain component circles and one accent movement cue. Evolution is not a numeric score, and movement cannot point left. Keep visual language consistent in every band.
+
+## Korean text
+
+Use Pretendard for component names and mono for band names, source notes, and concise timing tags. Use the exact evolution terms agreed by the project; if localizing them, keep the English band mapping in the legend or metadata. Place visible/invisible captions horizontally in Korean. Keep component names short and leave room for Hangul without shrinking the symbols. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+Preserve component positions, dependency topology, and rightward movement in every variant. Light/dark skins change only semantic colors; ensure dependency lines remain visible at their intended low emphasis. A full editorial version can add a title, one takeaway about build/buy/movement, and a source note around the same map, without moving points or claiming quantitative precision.
+
+## Accessibility
+
+Provide a title and description that explain both axes, every component's placement, and any movement arrow. Name the four bands visibly. Movement has both direction and text/legend meaning; do not use accent alone. Dependency links remain distinguishable from movement arrows by line style and arrowhead. Avoid rotated axis text and maintain contrast for small components and lines.
+
+## 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=wardley path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify band bounds, component/link caps, linked-component participation, and movement direction/count against source values and this guide; a matching ID alone does not prove those properties. Inspect dependency crossings and movement labels in both skins.
+
+## Anti-patterns
+
+- Treating evolution as a continuous numeric maturity score.
+- Numbering the visibility axis or implying it is measured.
+- A component with no dependency connection, or a leftward movement arrow.
+- Runtime request/response flow drawn as map dependencies.
+- Too many movement arrows or a label that simply restates “toward commodity.”
+- Vertical-writing axis captions or movement labels placed over a dependency crossing.
+
+## Related references
+
+[Architecture](type-architecture.md) · [Dependency graph](type-dependency.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-waterfall.md

@@ -0,0 +1,54 @@
+# Waterfall chart
+
+**Catalog ID:** `waterfall`
+
+## Purpose and selection
+
+Use a waterfall to show how a start total becomes an end total through signed sequential contributions: a budget bridge, headcount change, conversion gains/losses, or a P&L walk. The running total must reconcile at every step. Use a dumbbell for two endpoints where only the gap matters, a bar chart for independent category values, Sankey for branching quantity flow, and funnel for ordered drop-off.
+
+## Content schema
+
+Provide 3–8 bars total: a positive start total, at least one signed nonzero delta, an end total, and optionally one subtotal. Each bar has a stable name, role (`total`, `delta`, `subtotal`), value, unit, and displayed label. Deltas carry an explicit plus or minus sign. Include a single linear domain, source, period, and any “Other” aggregation definition. Totals and deltas use the same unit.
+
+For an SVG implementation, bind `data-role`, signed `data-value`, and `data-name` on every bar; bind the running level on each carry connector with `data-carry`. The verifier recomputes the walk from the declarations and compares it with the displayed geometry.
+
+## Deterministic layout recipe
+
+1. Use vertical bars in left-to-right order: starting total, signed contributions, optional subtotal, and ending total. Select a common linear y-scale whose domain includes zero and every running total; zero is the baseline for total bars.
+2. Draw start, subtotal, and end totals from the baseline to their values. Each delta bar spans exactly from the prior running level to the next. Draw a horizontal carry between adjacent bars at the exact level it transports.
+3. Reconcile `start + Σ(delta) = end` before placing any geometry. Carry levels reflect every intermediate sum. Round only at the final pixel coordinate; never adjust a bridge for visual convenience. Zero deltas are omitted and explained in a note if material.
+4. Give bars equal width and pitch, with sufficient space for category labels. Place totals/increases' value labels above their top; place decrease labels below their lower edge where the incoming carry does not collide. Print every delta with its sign.
+5. Use 3–8 bars total, including endpoints, and no more than one subtotal. If there are too many contributions, combine a justified tail into a named “Other” bridge or split the reconciliation into two views.
+
+## Visual encoding
+
+Totals use the strongest neutral outline/fill, increases a light filled treatment, and decreases a hollow treatment. This distinguishes sign in grayscale as well as color. One focal bridge may use the accent; it retains its signed label and geometric direction. Carries use a clearly visible rule because they assert conservation. Axes and gridlines are secondary, while values, signs, and bridge endpoints are primary.
+
+## Korean text
+
+Use Pretendard for categories and mono for exact values, units, and source notes. Print explicit `+`/`−` signs for all changes, regardless of Korean wording. Use one thousands-separator and decimal policy throughout and state whether values are rounded. Keep category labels short and upright; use `기초`, `증가`, `감소`, and `기말` only when they match the accounting meanings. Follow [Korean typography](korean-typography.md).
+
+## Light, dark, and full variants
+
+The values, scale, carries, bar roles, and focal bridge stay unchanged across variants. Light and dark skins use semantic tokens for paper, ink, and accent; a decrease remains hollow in both. The full editorial form can add a headline about the main contribution, one sentence on reconciliation, and source/period metadata. Verify carry visibility and value-label contrast in the dark skin.
+
+## Accessibility
+
+Provide a title and description with the starting amount, signed walk, ending amount, unit, and reconciliation result. Every bar prints its value, and each delta includes its sign. Fill state and geometry redundantly indicate direction; hue is never the only cue. Ensure carry levels are visible and text does not overlap them. Offer an equivalent table of start, delta, running balance, and end values for exact access.
+
+## 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=waterfall path/to/diagram.html` to check catalog identity and structural rules registered for that ID. Separately verify the running total, bridge geometry, carry levels, role/value bindings, signed labels, bar count, and domain against source values and this guide; a matching ID alone does not prove those properties. Review every value label at final output resolution; a mathematically valid chart may still have an illegible decrease label.
+
+## Anti-patterns
+
+- A floating delta without a carry or a carry at the wrong running level.
+- Unreconciled end total, mixed units, or unsigned delta labels.
+- Sign encoded by red/green hue alone.
+- A truncated or changing axis that exaggerates bridge size.
+- Multiple subtotals, zero-height bars, or more than eight columns.
+- Rounded geometry or labels that disagree with the declared values.
+
+## Related references
+
+[Bar chart](type-bar.md) · [Sankey](type-sankey.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/verifier-guide.md

@@ -0,0 +1,31 @@
+# Product-local diagram verification
+
+All authoring checks use Python standard-library modules plus the LitHermes plugin's installed `humanizer_detector`. Run them from the installed skill directory; no package installation or network access is needed.
+
+## Per-document checks
+
+~~~sh
+python3 scripts/verify-diagram.py --canvas path/to/diagram.html
+python3 scripts/verify-type.py --type=deployment path/to/diagram.html
+python3 scripts/verify-brief.py --brief path/to/brief.md path/to/diagram.html
+python3 scripts/verify-motion.py path/to/diagram.html
+python3 scripts/check-visible-text.py path/to/diagram.html
+~~~
+
+The commands emit JSON with issue codes and return nonzero when a check fails. `verify-diagram.py` checks SVG structure, finite geometry, text and node overlap, clipping, routes, contrast, accessibility metadata, and visible-text findings. `--canvas` also enforces the complete-artifact title, font, and content-fill floors. Run `verify-type.py` with the exact catalog ID and `verify-brief.py` against the brief that defines required content and boundary membership.
+
+`verify-motion.py` detects source patterns such as SMIL animation, unbounded CSS/JavaScript motion, and missing reduced-motion markers. It cannot prove that the static composition is complete or that controls are accessible, so review those properties separately. `check-visible-text.py` extracts visible SVG/document text before applying the exact installed LitHumanizer rules; it does not treat CSS or markup as prose.
+
+## Corpus review
+
+~~~sh
+python3 scripts/verify-all.py
+~~~
+
+The corpus command audits the reference/template catalog, all catalog templates, and the eight approved after-examples. It applies general diagram and type checks to templates, then canvas and brief checks to after-examples. It reports the number checked and every issue; a missing catalog resource is not a pass.
+
+## What the checks prove
+
+A passing verifier result proves only the properties its source checks can observe. It does not prove that a browser rendered the intended picture, that an Office application preserved every glyph, or that a factual claim is true. Rendered-image inspection remains a separate gate. Review geometry, source facts, language, font loading, and the final destination at the size readers will use.
+
+Quantitative and semantic type contracts inspect explicit SVG structure and declared data. Where the source lacks an observable contract, keep the limitation visible and compare the diagram with its source brief; do not turn unavailable evidence into a passing claim.

package/assets/lithermes-plugin/skills/lit-diagram-drawer/scripts/block-registry.mjs

@@ -0,0 +1,43 @@
+import path from 'node:path';
+
+const fields=['parent','name','input','output','constraint','assumption','impl'];
+const decode=(value)=>value.replaceAll('&amp;','&').replaceAll('&lt;','<').replaceAll('&gt;','>').replaceAll('&quot;','"').replaceAll('&apos;',"'");
+
+function buildBlockRegistry(svg, sourceName) {
+  const blocks=[];
+  for(const match of svg.matchAll(/<([\w:-]+)\b([^>]*)>/g)) {
+    const raw=match[2];
+    if(!/\bdata-block-id\s*=/.test(raw)) continue;
+    const attrs=Object.fromEntries([...raw.matchAll(/([\w:-]+)\s*=\s*(?:"([^"]*)"|'([^']*)')/g)].map((item)=>[item[1],decode(item[2]??item[3]??'')]));
+    const id=(attrs['data-block-id']||'').trim();
+    if(!id) throw new Error('REGISTRY_ID_REQUIRED');
+    const block={id};
+    for(const field of fields) {
+      const value=attrs['data-block-'+field];
+      if(value!==undefined&&value!=='')block[field]=value;
+    }
+    blocks.push(block);
+  }
+  if(!blocks.length) throw new Error('REGISTRY_BLOCKS_MISSING');
+  const ids=new Set();
+  for(const block of blocks) {
+    if(ids.has(block.id)) throw new Error('REGISTRY_DUPLICATE_ID '+block.id);
+    ids.add(block.id);
+  }
+  for(const block of blocks) if(block.parent&&!ids.has(block.parent)) throw new Error('REGISTRY_PARENT_MISSING '+block.id+' -> '+block.parent);
+  const byId=new Map(blocks.map((block)=>[block.id,block]));
+  for(const block of blocks) {
+    const seen=new Set([block.id]);
+    let parent=block.parent;
+    while(parent) {
+      if(seen.has(parent)) throw new Error('REGISTRY_CYCLE '+block.id);
+      seen.add(parent);
+      parent=byId.get(parent)?.parent;
+    }
+  }
+  const roots=blocks.filter((block)=>!block.parent);
+  if(roots.length!==1) throw new Error('REGISTRY_ROOT_COUNT '+roots.length);
+  return {schemaVersion:1,source:path.basename(sourceName),blocks};
+}
+
+export { buildBlockRegistry };

package/assets/lithermes-plugin/skills/lit-diagram-drawer/scripts/browser-version.mjs

@@ -0,0 +1,12 @@
+/** Return whether an agent-browser version is stable and at least 0.38.1. */
+export function agentBrowserSupported(output) {
+  const match = String(output).match(
+    /(?:^|\s)v?(\d+)\.(\d+)\.(\d+)(?:-([0-9A-Za-z.-]+))?(?:\+[0-9A-Za-z.-]+)?(?=\s|$|\))/,
+  );
+  if (!match) return false;
+  const [major, minor, patch] = match.slice(1, 4).map(Number);
+  if (major !== 0) return major > 0;
+  if (minor !== 38) return minor > 38;
+  if (patch !== 1) return patch > 1;
+  return !match[4];
+}

package/assets/lithermes-plugin/skills/lit-diagram-drawer/scripts/check-visible-text.py

@@ -0,0 +1,12 @@
+#!/usr/bin/env python3
+# /// script
+# requires-python = ">=3.10"
+# dependencies = []
+# ///
+# ─── How to run ───
+# python scripts/check-visible-text.py <text.txt|diagram.html|diagram.svg>
+
+from diagram_cli import check_visible_text_main
+
+if __name__ == "__main__":
+    raise SystemExit(check_visible_text_main())