@litfamily/litopencode 1.0.7 → 1.0.9

package/skills/lit-diagram-drawer/references/type-data-flow.md

@@ -0,0 +1,51 @@
+# Data Flow
+
+**Catalog ID:** data-flow
+
+## Purpose and selection
+
+Use this type for a typed data pipeline where the reader needs to see which role acts at each step and how a payload changes. It suits ingestion, storage, transformation, analysis, and publication flows with ownership lanes. Use a business swimlane for approvals or service operations where actors and task handoffs matter more than data types. Use DP integration for a topology of platform endpoints without a stage sequence.
+
+## Content schema
+
+Declare 1–4 ordered roles, each with a two-line display name and a unique short key. Declare 1–6 ordered pipeline steps with number and short label. Add only real role-step nodes; absent participation stays empty. A node may have a title, one-line action, tool or system, optional input/output payload codes, and a focal flag. Declare edges explicitly by node IDs, with direction and one of four meanings: ordinary handoff, governance trigger, focal cross-role handoff, or published output. The schema has three focal slots: one step, one receiving node, and one incoming cross-role edge. Populate exactly one of each; if the brief has no meaningful focus, select a different type instead of fabricating one. Keep custom concern colors to a few clearly named meanings.
+
+## Deterministic layout recipe
+
+Derive the viewBox width as 140px for the role rail plus 112px per step plus 28px right padding. Set the header to 36px, each lane to 80px, and the legend to 80px; use 100px for the legend when a concern-color row is required. Thus viewBox height is 36 + 80 × lane count + legend height. Step center j is x=140 + 112j + 56. Lane top k is y=36 + 80k. Place a node at x=center−50 and y=lane top+8; every node is 100 × 64. Empty cells have no shape, text, or placeholder. Center the lane's two-line name in its left rail and mark lane boundaries with quiet rules.
+
+Each node can hold a compact role tag, title, short action, and tool label. Put its input payload chip at bottom-left and output chip at bottom-right; omit a chip only when the node has no input or output. Keep chip meanings in a small horizontal legend. The focal step uses an accent header, the receiving node has the focal outline, and the incoming focal edge is the only labeled accent route.
+
+Draw edges before nodes. Route same-lane edges from the right side to the next node's left side. Route cross-lane edges with an orthogonal single bend and an 8px corner, using a top or bottom port for a vertical arrival. Stagger shared ports by at least 12px. Label only the focal handoff; place its text on a paper mask with a clear gap around the route. Keep the legend in a horizontal strip below the lanes.
+
+## Encoding rules
+
+Step position communicates sequence; lane position communicates ownership; node text names the work; payload chips show input and output shape. Use distinct neutral line styles for standard data handoff and governance triggers. The one focal transfer uses the accent and a short payload label. Input and output codes describe payload format independently from any node tint. If semantic concern colors are used, name them in the legend and keep connectors' colors tied to edge meaning, never to node color. Leave non-focal edge labels blank to protect the grid from text collisions.
+
+## Korean behavior
+
+Use Korean role and action names when the operating audience uses Korean. Preserve exact system names and payload codes; add Korean explanations for unfamiliar abbreviations. Use Pretendard for node copy and mono for step numbers, payload codes, protocols, and role IDs. Keep two-line lane labels consistent, and allow Hangul node titles to wrap without shrinking the text. Make a chip's spoken alternative explicit, for example “입력: 테이블”.
+
+## Light, dark, and full variants
+
+Light uses alternating low-contrast lane fills only when they improve tracking, plus restrained dividers. Dark reverses the dividers, lane tint, and chip surfaces while preserving the same row/column geometry and flow styling. Full may add a short title and takeaway and a horizontal legend. Do not add placeholders or summary cards that duplicate every node.
+
+## Accessibility
+
+The description should state the role order, pipeline stages, focal handoff, and what payload-chip positions mean. Keep the SVG title and description, with reading order following lanes then steps. Pair line pattern and label with color. Offer a text sequence or table when every transfer must be read exactly. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for route overlap, clipping, contrast, accessibility, and text checks. Run scripts/verify-type.mjs --type=data-flow for schema bounds, empty-cell behavior, exactly one focal entry in each required slot, edge endpoints, routing, and payload-chip placement. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Drawing empty cells as faded placeholder boxes.
+- Labeling every edge instead of reserving one label for the central handoff.
+- Using diagonal arrows or encoding role, flow, and concern with competing color systems.
+- Showing tools without showing who performs the work.
+- Changing payload codes to localized labels without preserving their technical identity.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Icons](primitive-icons.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-datalake.md

@@ -0,0 +1,49 @@
+# Data Lake Overview
+
+**Catalog ID:** datalake
+
+## Purpose and selection
+
+Use this high-level architecture variant to explain an unclustered data-lake stack from external sources through ingestion and storage to query and consumers. It is suited to an end-to-end orientation where the lake is the central point of the story and no container-orchestrator boundary is needed. Use the high-level architecture type when deployment cluster and cross-cutting concern strips are essential. Use DP integration when each integration endpoint and protocol must be inventoried.
+
+## Content schema
+
+Declare ordered phases, normally Sources → Ingest → Data Lake → Query → Consume. List external inputs, ingestion components, the lake/store, query or transform tools, and downstream consumers. Each component has a stable ID, phase, visible name, optional sublabel, and optional icon key. Declare directed connections, label the important data transfer, and identify one focal lake/store. Include only the systems needed to explain this path; record any omitted platform services in a caption.
+
+## Deterministic layout recipe
+
+Use a 1000 × 488 viewBox. Place five phase zones at y=32: Sources x=4 w=160, Ingest x=176 w=160, Data Lake x=380 w=184, Query x=600 w=168, and Consume x=804 w=164. These fixed gutters leave room for orthogonal routes. Put phase names at each zone center near y=44. Use 56px-high component nodes; align the common node rows at y=60, 164, and 268, leaving an 8px gap within the 104px pitch. The consumer zone may use all three rows, source and query zones generally use two, and the lake zone holds one focal storage node. If node counts exceed these slots, split the overview instead of compressing them.
+
+Draw zone surfaces first, then arrows, then nodes. Use straight segments only for aligned endpoints; otherwise use rounded right-angle paths. Sort routes by source then destination ID. The central storage node is the single accent target. Reserve the lower band below y=312 for the occasional return/write-back path and the legend. Do not change phase widths to emphasize a vendor; use focal styling for the store.
+
+## Encoding rules
+
+Phase position carries sequence. A boundary distinguishes outside data sources from the platform. Neutral connectors represent movement; dashed routes are reserved for explicitly asynchronous or scheduled transfers. One accent marks the lake/store. Use icons as recognition aids only; every component still has a text name. Do not imply raw/curated quality states unless those states are supplied and named.
+
+## Korean behavior
+
+Use Korean phase names when useful, but retain exact product and service names. Explain “data lake” once as “데이터 레이크” or use the project's chosen term consistently. Use Pretendard for labels, mono for file formats and protocol identifiers, and keep Hangul line-height generous enough for two-line node titles. Format counts and units for ko-KR; preserve exact storage units in the data/caption.
+
+## Light, dark, and full variants
+
+Light uses a pale source boundary and one quiet phase rail. Dark uses a separate set of boundary and connector colors with verified contrast. Full adds one title, a one-sentence reading, and a compact legend or source note. The stack, lake focal point, scale, and system placement remain unchanged.
+
+## Accessibility
+
+Name the source region, central lake, and end consumers in the SVG description. Make the reading order follow the phase sequence. Icons must have adjacent text labels; don't encode source, storage, and consumer roles with icon shape alone. Provide a short text path for readers who cannot inspect the routes. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for the standard geometry, rendered clipping, contrast, accessibility, skin, and text checks. Run scripts/verify-type.mjs --type=datalake for five-phase order, focal-store uniqueness, endpoint validity, and route semantics. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Adding a Kubernetes boundary or a vertical concern strip when the brief does not need one.
+- Making every phase a decorative chevron with equal visual emphasis.
+- Treating the data lake as a generic database symbol without naming its role.
+- Showing a source-to-consumer bus when specific paths are known.
+- Introducing bronze/silver/gold semantics without evidence they exist in the system.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Icons](primitive-icons.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-db-schema.md

@@ -0,0 +1,49 @@
+# Database Schema
+
+**Catalog ID:** db-schema
+
+## Purpose and selection
+
+Use a database-schema diagram for physical tables, columns, SQL types, constraints, indexes, and foreign keys anchored to particular columns. It helps review a migration or explain deletion and nullability behavior. Use ER when the discussion is about conceptual entities and relationship cardinalities rather than real columns and types.
+
+## Content schema
+
+Supply 2–5 tables. Each has a schema-qualified name, ordered column list, exact SQL type, and optional constraint flags such as primary key, foreign key, unique, and not-null. Include at most 8 displayed columns per table, with an explicit “N more” row if the table is shortened. Declare foreign-key source and target column IDs and the referential action. Optionally list only story-relevant indexes. Keep names distinct and preserve the actual database spelling.
+
+## Deterministic layout recipe
+
+Use a 1000px-wide canvas with a 24px table gutter and a fixed table width derived from the longest displayed identifier, capped at 260px. Put tables in stable schema and table-name order, then place related tables in nearby columns. Each header is 40px; each column row is 24px. Use these fixed row centers as connector anchors. Draw schema boundaries first, then FK routes, then table surfaces, rows, constraints, and labels.
+
+Foreign-key lines connect the center of the actual source column row to the center of the referenced row. Use rounded orthogonal routes with an 8px bend and reserve 12px separation for multiple edges. When edges share a column-row anchor, fan their starting points symmetrically within that row. Give each edge a short referential-action label with an opaque background mask. Grow the canvas or split the schema rather than allowing routes to cross table text.
+
+## Encoding rules
+
+Use typography and constraint labels, not color, to distinguish column roles. Keep SQL types in a mono role aligned to the right. Show PK, FK, UQ, and NN tags only where they help the review. Accent only one consequential delete action and its affected table header, if the schema contains such a rule. Indexes belong in a separate final compartment and are limited to those relevant to the claim.
+
+## Korean behavior
+
+Keep physical table, column, constraint, and SQL type names exact; do not translate identifiers. Use Korean notes for business meaning and explain database-specific abbreviations once. Use Pretendard for explanatory labels and mono for SQL. Do not force Hangul into narrow type/name columns; grow table width or wrap only descriptive text. Use the literal SQL action spelling in FK labels.
+
+## Light, dark, and full variants
+
+Light uses clear row separators and a subtle alternating row tint. Dark rebuilds table, row, and connector contrast with dark-surface tokens and preserves the same schema. Full adds title, migration context, and a brief impact note outside the tables. It must not silently add columns or relationships.
+
+## Accessibility
+
+Include a textual schema summary and a table representation with column names, types, and constraints. The SVG description should identify the tables and important FK actions. Ensure PK/FK meaning is available as text rather than hue. Keep row labels and action labels readable at export scale. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for table clipping, route collisions, contrast, accessibility, and visible text. Run scripts/verify-type.mjs --type=db-schema for row-anchor alignment, FK resolution, constraint labels, and table/column budgets. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Drawing every column from a large production database.
+- Connecting table boxes instead of the specific foreign-key rows.
+- Omitting SQL types or referential actions that are the subject of the review.
+- Mixing conceptual entity names with physical table names.
+- Coloring every table or listing every index.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-dependency.md

@@ -0,0 +1,49 @@
+# Dependency Graph
+
+**Catalog ID:** dependency
+
+## Purpose and selection
+
+Use a dependency graph when a component has multiple dependents or a real dependency cycle prevents a tree from representing the structure. Use a tree if every item has one parent and the graph is acyclic. Use architecture when the goal is to show system communication rather than prerequisite structure.
+
+## Content schema
+
+Provide up to 9 package, module, or service nodes and up to 14 directed dependency edges. Each node has a stable ID, name, type (internal, external, or leaf), and optional version/registry label. Include fan-in count as a derived value. Declare one cycle for focal treatment at most. If the input is a DAG, state the ranking rule; if cyclic, mark the single back-edge explicitly.
+
+## Deterministic layout recipe
+
+Assign nodes to horizontal rank rows by dependency depth, with a fixed 120px vertical pitch. Use 160 × 56 node boxes, and order within each row by stable name or supplied order. Draw forward edges downward or horizontally within a rank. Route the one permitted cycle around the outside of the node field as a dashed return edge, never through unrelated nodes. Draw the cycle path and its label in accent; keep the touched nodes neutral. Place a derived fan-in badge within the node whose dependency concentration is the story.
+
+Draw edges before node surfaces. Route off-axis edges with rounded 8px elbows, maintain 12px spacing where edges fan out, and bridge a crossing only on the less important path. If more than four rank layers are needed, collapse a leaf cluster into a named aggregate with its count or split the view.
+
+## Encoding rules
+
+Direction means “depends on”; define arrow direction in the caption and use it consistently. Use a low-ink neutral style for internal nodes, a distinct outline for external dependencies, and a restrained leaf treatment. Fan-in is a numeric badge, not a new hue. Accent only the chosen cycle and its label. Version and registry belong in a technical sublabel.
+
+## Korean behavior
+
+Use Korean for relationship explanation and captions, while preserving package IDs, versions, and registry names exactly. Use Pretendard for names and mono for version/registry badges. State arrow direction in Korean because “A → B” may be read as either use or prerequisite direction. Avoid breaking package identifiers across lines.
+
+## Light, dark, and full variants
+
+Light uses neutral node fills and clear rank spacing. Dark uses separately tuned edges and external-node boundaries, preserving the same ranks. Full adds a title and a short note about the one marked cycle or highest fan-in node. Keep all nodes and edges identical across variants.
+
+## Accessibility
+
+Describe the direction convention, rank ordering, highlighted cycle, and highest fan-in dependency in text. Include a list or table of edges for exact dependency audit. Do not encode external/internal status by color alone. Keep badge text available to assistive technology. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for path collision, clipping, contrast, accessibility, and text checks. Run scripts/verify-type.mjs --type=dependency for endpoint resolution, rank order, fan-in counts, cycle limit, edge limits, and cycle routing. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Drawing a simple tree as a graph.
+- Letting ordinary forward dependencies point upward.
+- Turning every file into a node instead of modeling packages or modules.
+- Routing the highlighted cycle through unrelated nodes.
+- Omitting fan-in when dependency concentration is the reason to choose this type.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-deployment.md

@@ -0,0 +1,49 @@
+# Deployment
+
+**Catalog ID:** deployment
+
+## Purpose and selection
+
+Use deployment to show where software runs: environments, network zones, hosts, pods, managed services, artifacts, versions, replicas, and protocol paths. The placement decision must be visible. Use architecture when only logical communication matters and deployment placement adds no answer.
+
+## Content schema
+
+Declare up to 3 actual zones, each with an environment or network-boundary meaning. Each infrastructure node has a stable ID, type (host, VM, pod, managed service, CDN), zone, and name. Each artifact has a deployed version. A node may have a replica count. Edges record protocol and port, and optionally mark asynchronous or replication traffic. Limit the drawing to 6 infrastructure nodes, 9 artifact labels, and 8 network paths.
+
+## Deterministic layout recipe
+
+Use three nested levels in a 1000px-wide viewBox: outer zone, infrastructure node, then artifact chips within a node. Preserve zone order from public/edge to private/data unless the brief specifies another direction. Divide the interior of each zone into columns by declared node order; center nodes in their column and distribute vertically with fixed 24px gaps. Keep artifact chips in a stable version/name order, with 8px spacing. Put a replica badge inside the owning node.
+
+Draw zone boundaries first, then orthogonal network routes, then node frames and artifact rows. Use right/left ports for mostly horizontal paths and top/bottom ports for vertical paths. Label each path with protocol and port on a masked paper strip. A route crossing a zone boundary can use the link color; within-zone traffic remains neutral. Async or replication paths use a dashed stroke.
+
+## Encoding rules
+
+The boundary represents a real environment/network boundary, not just grouping. Node type is stated with a small text tag; artifact names carry explicit version values. Replicas are shown as one node plus a count, never cloned cards. Use at most two accent targets for a new component or a single point of failure and its consequential replication route.
+
+## Korean behavior
+
+Use Korean zone captions if the deployment audience works in Korean. Preserve cloud regions, hostnames, ports, image tags, and protocol names exactly; explain abbreviations in Korean nearby. Use Pretendard for descriptions and mono for versions, ports, and image identifiers. Keep counts as numerals and format dates/versions as technical tokens, not localized prose.
+
+## Light, dark, and full variants
+
+Light uses quiet zone fills with dashed boundary strokes. Dark redraws the zone tint and network paths for clear separation; never simply invert the light SVG. Full adds a title, deployment scope, and short legend outside the nested zones. Node count, zone placement, versions, and path endpoints must remain unchanged.
+
+## Accessibility
+
+Describe each zone's meaning, hosts/artifacts, replica counts, and the important network paths. Keep a text list of deployments and protocol/port values available. Every host icon has an adjacent name; boundary meaning is expressed with a label and line pattern, not hue alone. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for nested-boundary geometry, rendered clipping, contrast, accessibility, and text. Run scripts/verify-type.mjs --type=deployment for node/artifact/path limits, version tags, replica counts, and endpoint placement. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Repeating a logical architecture and sprinkling hostnames on top.
+- Drawing a zone without a real trust or environment meaning.
+- Omitting versions from deployed artifacts.
+- Drawing one node for each replica.
+- Replacing named infrastructure with a wall of vendor logos.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Icons](primitive-icons.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-dp-integration.md

@@ -0,0 +1,49 @@
+# Data Platform Integration
+
+**Catalog ID:** dp-integration
+
+## Purpose and selection
+
+Choose this type to inventory the systems that connect into a data platform, the platform components they touch, the consumers it serves, and the protocols on those links. It is a topology, not a timeline. Use data flow when ownership across sequential stages is central; use the security matrix when permissions are central.
+
+## Content schema
+
+Declare external sources, an ordered platform interior, consumers, and optional cross-cutting services such as identity or observability. Each endpoint has a stable name, kind/icon key, optional subtitle, and explicit connections. Connections name both ends and carry protocol or purpose. Platform rows may be a full-width service bar or a row of peer components. Limit ordinary source and consumer groups to six each; keep the common case near 14–20 named nodes only when the integration surface itself is the message. Combine truly identical systems with a count and split domains that create a hairball.
+
+## Deterministic layout recipe
+
+Use a 1200px-wide viewBox. Reserve 160px side columns at x=40 and x=1000 for sources and consumers. Place source/consumer nodes at y=92 plus 88px per row, with 64px height. Center the platform zone between them at x=260 with width 696; its height matches the side columns and has explicit padding. Allocate platform bars and peer rows top-to-bottom from a cursor, keeping the primary component row vertically aligned with the second side-column row. Put cross-cutting bars below the zone, each 56px high with 8px separation. Derive canvas height from the last footer and reserve a legend band.
+
+Draw the platform boundary, then connectors, then nodes and footer bars. Edges between side columns and platform use right-to-left ports; bar-to-component triggers leave the bar bottom and enter from the component top. Cross-cutting services connect to the platform boundary, not an arbitrary tool. Route with orthogonal 8px elbows, stagger repeated fan-out ports, and label meaningful protocol edges on clear masks. Avoid intersections; use a small bridge only when rerouting is impossible.
+
+## Encoding rules
+
+Sources stay visibly outside the platform boundary; consumers stay on the opposite side. Internal paths are neutral, protocol/federation paths use a distinct dashed style, and orchestration triggers are dashed and unlabeled if their meaning is in the legend. A focal component or focal handoff may use the accent. Identity and observability remain cross-cutting services rather than ordinary platform nodes. Do not color every vendor differently.
+
+## Korean behavior
+
+Use Korean for section names and captions while retaining exact service names, protocols, and ports. Use Pretendard for visible names and mono for protocol labels, identifiers, and codes. Explain technical abbreviations once; avoid line breaks within API names. When localizing source/consumer labels, retain exact English platform product names.
+
+## Light, dark, and full variants
+
+Light uses a dashed source/platform boundary, a quiet platform surface, and restrained neutral edges. Dark rebuilds these boundaries and the protocol palette for contrast. Full adds title, takeaway, scope, and a compact legend beneath the drawing. Preserve every endpoint, path, and count between variants.
+
+## Accessibility
+
+Describe the platform boundary and the main source-to-platform-to-consumer paths. Provide a route table for protocol and endpoint details. Include text beside every icon, identify line styles in a legend, and preserve reading order from sources through the platform to consumers. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for zones, edge overlaps, clipping, contrast, accessibility, and text. Run scripts/verify-type.mjs --type=dp-integration for side-column budgets, endpoint integrity, zone geometry, footer behavior, and connector style rules. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Collapsing several known endpoints into one “sources” or “consumers” node.
+- Replacing labeled connections with one bus arrow.
+- Coloring every tool as though vendor identity were the hierarchy.
+- Placing identity inside the boundary when it governs all platform components.
+- Mixing a phase chevron banner into a topology with no phase question.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Icons](primitive-icons.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-dp-security-matrix.md

@@ -0,0 +1,49 @@
+# Data Platform Security Matrix
+
+**Catalog ID:** dp-security-matrix
+
+## Purpose and selection
+
+Use a permissions matrix to audit which roles can perform which actions on data-platform components. Rows are resources; columns are roles or groups. Choose DP integration when the question is which systems connect and by what protocol. Choose a process or sequence type when explaining how access is granted.
+
+## Content schema
+
+Declare 2–6 ordered roles and 2–14 ordered components. Each role has a visible name and optional group identifier. Each component has a name and optional short hint. Supply a complete permission for every role/resource pair; omitted cells mean the declared “no access” state only when that is factually correct. Use a closed permission class: full/admin, read-write, read, or none. Display text can be “SELECT”, “Login”, or a domain term, but its class must remain explicit. Mark zero or one focal cell and optionally add a short explanation line.
+
+## Deterministic layout recipe
+
+Place the resource-name column first, then role columns. Reserve 208px for resources, 148px for each role column, 16px column gaps, 12px left padding, and 48px right padding. Role header height is 52px. Start resource rows at y=140; use 40px row pitch and 36px cell height. Derive width from the role count and height from the resource count, then place the legend below the final row. Keep values centered in cells and component names left aligned.
+
+Each cell uses the same border and text alignment. Differentiate permission classes with a restrained fill and explicit displayed permission words. Draw no arrows. If six roles or fourteen resources are exceeded, split the matrix by role family or platform domain.
+
+## Encoding rules
+
+Cell text is the policy; tone is only reinforcement. Use the same class-to-style mapping in every row and every theme. Accent a single critical rule, not a whole row or column. Show a legend only for permission classes present. Distinguish unknown or unreviewed access from “none”; never turn missing evidence into an implied denial.
+
+## Korean behavior
+
+Use Korean role names and resource hints where the organization uses them. Preserve group IDs, database permissions, and exact role names as technical identifiers. Use Pretendard for Korean headers and mono only for literal group or permission codes. Keep all cells tall enough for Hangul; if labels need two lines, increase the shared row height rather than shrinking one cell's text.
+
+## Light, dark, and full variants
+
+Light uses neutral cells and one accent focal cell. Dark uses a dark surface with distinct permission-class tones, visible cell boundaries, and readable text; check all classes for contrast instead of reusing light fills. Full adds a title, scope, and a concise legend; it must not imply unlisted permissions. Keep matrix dimensions and all values fixed between variants.
+
+## Accessibility
+
+Expose the matrix as a semantic table or provide an equivalent table next to the SVG. Give column/row headers proper associations. Permission meaning must appear as text and not color alone. The description should name the focal access rule and state how “no access” is represented. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for contrast, text clipping, accessibility, and theme checks. Run scripts/verify-type.mjs --type=dp-security-matrix for complete cell coverage, closed permission classes, matrix bounds, and focal-cell limits. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Drawing connectors between cells.
+- Treating an omitted or unknown permission as “no access”.
+- Highlighting whole rows or columns when one intersection is the claim.
+- Adding unrestricted free-form categories that make styles incomparable.
+- Cramming an organization-wide role list into unreadable columns.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-er.md

@@ -0,0 +1,49 @@
+# Entity–Relationship Model
+
+**Catalog ID:** er
+
+## Purpose and selection
+
+Use ER for conceptual or logical data models where entities, attributes, and relationship cardinality are the core message. The edges connect entity boxes and state multiplicity at each end. Use database schema when actual SQL types, indexes, constraints, delete actions, or column-to-column foreign keys matter.
+
+## Content schema
+
+Each entity has a stable ID, visible name, and a short list of fields. Mark the key field and distinguish foreign-key references when useful. Each relationship has source entity, target entity, cardinality at both ends, and an optional verb phrase. Limit the view to a readable domain slice; if the drawing contains dozens of entities, split by bounded context rather than omit relationships silently.
+
+## Deterministic layout recipe
+
+Use a 1000px canvas with 32px margins. Place a central aggregate or focal entity near the horizontal center. Place directly related entities in the nearest surrounding columns; use a stable order by domain or name to position peers. Entity boxes have a header band and a naturally sized field list; do not pad all boxes to equal height. Draw relationship lines before entity surfaces. Route edges with rounded orthogonal elbows where possible, and use straight horizontal or vertical routes for aligned entities. Put cardinalities just outside each entity boundary and labels near the line midpoint with an opaque background.
+
+When relationships exceed the available space, use clusters and a legend or split the domain. Use arrows only if direction has actual domain meaning; cardinality is required whether or not an arrow is present.
+
+## Encoding rules
+
+The entity name is primary; fields are secondary. Use explicit PK and FK text markers rather than color. Cardinality values must use one notation consistently and appear at both ends. One central entity may receive accent emphasis. Relationship names are optional but should be concise verbs such as “places” or “belongs to”.
+
+## Korean behavior
+
+Use Korean for domain names and relationship verbs when the team models in Korean. Keep database/API identifiers exact in parentheses or technical sublabels. Use Pretendard for entity names and Korean descriptions, mono for field IDs and key markers. Do not translate cardinality symbols; accompany them with a Korean accessible explanation if the audience needs it. Wrap Korean fields at safe word boundaries.
+
+## Light, dark, and full variants
+
+Light uses a quiet field, crisp entity dividers, and one focal entity. Dark uses separate text, field, and connector tokens with verified contrast. Full adds a short model scope and a note describing any omitted subdomain; it does not add decorative cards behind every entity. Entity placement and relationship semantics remain identical.
+
+## Accessibility
+
+Provide a text or table alternative listing entities, fields, and each relationship's two cardinalities. Include an accessible description of the model boundary and focal entity. Ensure key status is stated textually and not only through color or position. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for edge overlaps, clipping, contrast, labels, and accessibility. Run scripts/verify-type.mjs --type=er for entity/relationship reference integrity and cardinality presence and consistency. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Drawing every foreign key as an edge on a very large model.
+- Mixing physical SQL details with a conceptual domain model.
+- Using inconsistent cardinality notation across related edges.
+- Filling entity boxes with padding just to make their heights match.
+- Omitting one endpoint cardinality or relying on line shape to imply it.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-fishbone.md

@@ -0,0 +1,49 @@
+# Fishbone Root-Cause Diagram
+
+**Catalog ID:** fishbone
+
+## Purpose and selection
+
+Use a fishbone to organize investigated candidate causes of one observed effect. It helps a postmortem show how evidence was grouped and where a confirmed cause sits. Use a timeline or sequence when events happened in order. Use a causal graph if causes form a directed chain or interact across branches.
+
+## Content schema
+
+State one observable effect, phrased as a symptom or measurement rather than a fix. Provide 3–5 investigation categories, each with 1–3 specific sub-causes. Mark at most one confirmed root cause and distinguish it from candidates that remain unconfirmed. Category names must come from the actual investigation, not a blank “6M” checklist. Add evidence status in a short note when it affects interpretation.
+
+## Deterministic layout recipe
+
+Use a 1480 × 600 viewBox starting at x=−40, with the spine centered at y=320 and the effect box starting at x=1200. For bone k from 1 through 5, place its spine attachment at x=1200−160−160k. Alternate bones above and below the spine. Its category endpoint is 96px left and 168px above or below its attachment. These 60-degree diagonals are the defining grammar and the only exception to orthogonal routing. Put the category label at the far endpoint. Place two sub-cause ticks at one-third and two-thirds of each bone; with one item, use the midpoint; keep each tick 32px long and place one concise label beyond its open end. The default five-bone frame is already at its left bound for an extra bone. To add a sixth, widen both effect position and viewBox by at least 160px, or split the analysis.
+
+Draw the spine first, then category bones, ticks, labels, and the effect box. Use consistent geometry per category and stable category order. Highlight only the confirmed cause branch and effect using the two-item accent budget; candidate branches stay neutral. Ensure the outer category tags and effect box remain within the declared viewBox.
+
+## Encoding rules
+
+The spine points toward the observed effect. Each large bone represents a cause category; short ticks are sub-causes. Candidate and confirmed findings must be textually distinguished. Accent is reserved for one confirmed branch and the effect. Do not make all category lines different colors.
+
+## Korean behavior
+
+Use Korean for the observed effect and category/sub-cause labels when appropriate. Keep metric names and units exact, e.g. p95/p99, latency, or error rate. Use Pretendard for cause text and mono for measurements. Give diagonal labels room to remain horizontal where possible; do not rotate Korean text along a bone. Keep evidence status concise and avoid internal ticket syntax in visible text.
+
+## Light, dark, and full variants
+
+Light uses a clear neutral spine and quiet candidate bones; the confirmed branch uses a single accent. Dark changes the spine and labels to an accessible light-on-dark ramp. Full may add a compact summary of confirmed versus open causes below the same drawing. It must not imply that an unconfirmed hypothesis was established.
+
+## Accessibility
+
+Describe the effect first, then enumerate categories and sub-causes in a logical reading order. State which cause is confirmed. Do not rely on accent to separate confirmed from candidate causes. Offer the cause list as adjacent text or a table. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for bounds, overlaps, text fit, contrast, and accessibility. Run scripts/verify-type.mjs --type=fishbone for bone and sub-cause counts, branch geometry, confirmed-cause budget, and effect-box bounds. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Treating a timeline as a fishbone.
+- Phrasing the effect as a remedy.
+- Adding empty generic cause categories to satisfy a template.
+- Marking multiple causes as confirmed with one focal treatment.
+- Overrunning the canvas with a sixth diagonal branch and a clipped effect box.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Annotation primitives](primitive-annotation.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-flowchart.md

@@ -0,0 +1,49 @@
+# Flowchart
+
+**Catalog ID:** flowchart
+
+## Purpose and selection
+
+Use a flowchart for decision logic, algorithms, user-facing routing, or a bounded support/onboarding path. Use a sequence diagram when actor messages and time order matter, and a state machine when the same entity persists through named states and transitions.
+
+## Content schema
+
+Provide one start node, ordered action nodes, decision nodes with a question, and one or more terminal nodes. Each edge has a source, destination, and branch label when it leaves a decision. Keep decisions to at most three exits; split higher-arity choices into nested questions. Declare one happy path or one consequential decision for focal emphasis. Keep the common case to about nine nodes and twelve edges.
+
+## Deterministic layout recipe
+
+Use a 1000px-wide canvas with a top-to-bottom primary route. Put start first, then actions and decisions in topological rows. Assign each node a stable row and branch column from the input order. Align centers to a 4px grid and reserve at least 64px vertical gap between node bounds. Shape grammar is fixed: oval for start/end, square-corner rectangle for action, diamond for decision, and a small neutral dot for a merge. Route orthogonally using 8px elbows; place branch labels near the first segment on paper masks. Draw edges before nodes.
+
+If branches rejoin, merge them before continuing. When crossings cannot be removed by reordering, bridge one lower-priority edge. Split a dense decision tree into overview plus detail rather than compressing node text.
+
+## Encoding rules
+
+Shape carries node type; text labels each outgoing decision branch. Use one accent on the happy path or the most consequential decision, not both if that would exceed the accent budget. Keep all other paths neutral. Do not use color as a substitute for start/action/decision/end shape.
+
+## Korean behavior
+
+Write decision questions as short Korean questions and label every branch with a complete answer such as “예” or “아니요”. Use Pretendard for prose and keep English product names or commands intact in a technical sublabel. Avoid overly long diamond text; place explanation in a nearby note rather than shrinking type. Ensure the accessible description follows branch order.
+
+## Light, dark, and full variants
+
+Light uses paper surfaces, ink outlines, and one path accent. Dark rebuilds node fills and outlines to retain clear shape boundaries. Full adds title, purpose, and a short legend only if line styles need explanation. Preserve branch topology and node positions between themes.
+
+## Accessibility
+
+Include a textual step list with the decision branches, because a static image cannot by itself provide branching navigation. The SVG description should name the start and terminal outcomes. Branch labels must be visible and programmatically associated with their edges or nearby nodes. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for node collision, branch-label clipping, contrast, accessibility, and visible text. Run scripts/verify-type.mjs --type=flowchart for node-shape grammar, branch labels, decision exits, reachability, and edge budgets. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Using fill colors to indicate action versus decision.
+- Leaving yes/no or other decision branches unlabeled.
+- Giving a diamond four or more exits.
+- Crossing branches when a deterministic column reordering would avoid it.
+- Making the diagram so dense that a text checklist is easier to follow.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Semantic patterns](semantic-patterns.md) · [Annotation primitives](primitive-annotation.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-gantt.md

@@ -0,0 +1,49 @@
+# Gantt Chart
+
+**Catalog ID:** gantt
+
+## Purpose and selection
+
+Use Gantt when tasks have explicit start and finish points and the reader needs to compare overlap, parallel work, and milestones. Use a timeline for a small event sequence without task duration, or a roadmap when work is only ordered by phase and no calendar scale is trustworthy.
+
+## Content schema
+
+Provide a date range, time unit, and 3–12 tasks. Each task has a stable ID, name, start, end, and optional phase or track. Dates must fall within the stated range and end must not precede start. Declare one focal deliverable or critical task. A milestone is a point event, not a zero-width bar. State the “today” date only when it is relevant and current.
+
+## Deterministic layout recipe
+
+Use a 1000 × 500 canvas. Reserve x=200..960 for the time scale and a 180px task-label rail. Allocate 40px per task row; bars are 24px high and vertically centered in that row. Derive bar x and width from the same linear time range, rounding edges only after computing the date-to-pixel mapping. Place 4–8 equal-interval time ticks above the rows. Group tasks by phase with a subtle background rule and a text label. Add an optional dashed “today” marker at its derived x-position.
+
+Keep dependencies out of the basic Gantt; if essential, add only a few explicit orthogonal annotations and route them behind no task bar. Use stable row order from the content schema. Grow canvas height to fit tasks and labels rather than compressing row height.
+
+## Encoding rules
+
+Horizontal length represents duration on a shared calendar scale; row position identifies the task. A single accent bar marks the focal deliverable. Use light neutral fills for other tasks. Use shape or line style for milestones and today markers, each with a legend entry. Put start/end dates on the axis or in data, not inside the bar.
+
+## Korean behavior
+
+Use Korean task and phase names with Pretendard. Use the project's locale and calendar convention consistently; state timezone if dates are tied to system events. Format month/week labels compactly and use mono for exact dates. Avoid crowding Korean task names by widening the label rail or wrapping to two lines. Never reduce bar length to fit translated text.
+
+## Light, dark, and full variants
+
+Light uses subtle phase bands, neutral bars, and one accent bar. Dark recalculates band and bar fills to preserve visible boundaries. Full adds title, date range, and a short milestone/source note. The axis range, task dates, and bar widths remain the same in every variant.
+
+## Accessibility
+
+Provide a table listing each task's start and end date and phase. Describe overlaps and key milestone in the accessible summary. Ensure that phase grouping and milestone identity are stated in text, not only by fill. See [Accessibility](accessibility.md).
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs for bar bounds, clipping, contrast, and accessibility. Run scripts/verify-type.mjs --type=gantt for date validity, shared time mapping, task count, focal-bar limit, and milestone shape. See [Verifier guide](verifier-guide.md).
+
+## Anti-patterns
+
+- Showing more than twelve detailed tasks without splitting into plans.
+- Using bars without known start and finish dates.
+- Giving every bar the same emphasis.
+- Putting dates inside bars where they collide with names.
+- Adding dependency arrows everywhere until the schedule becomes a network diagram.
+
+## Shared references
+
+[Style guide](style-guide.md) · [Output specification](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Verifier guide](verifier-guide.md) · [PPTX and DOCX](office-pptx-docx.md)

package/skills/lit-diagram-drawer/references/type-heatmap.md

@@ -0,0 +1,53 @@
+# Heatmap
+
+Catalog ID: heatmap
+
+## Purpose and selection
+
+Use a heatmap when a complete row-by-column matrix needs to be scanned and the important comparison is which intersections are relatively stronger or weaker. Typical inputs are service × release, team × week, or class × predicted label. Treat every cell as data, not decoration. Choose one editorial focal cell only when the title makes a claim about that exact intersection.
+
+## Exclusions
+
+Use a table when there are fewer than three rows or columns, a line chart when order and change over time dominate, and a bar chart when readers must compare exact values across categories. Use a diverging palette only for signed values around a meaningful zero or midpoint. If labels force cells below a legible size, split the matrix or summarize it; do not silently remove categories.
+
+## Content schema
+
+Provide a title that states the comparison; complete ordered row and column labels; one numeric value for every intersection; unit and period; any filter or missing-data rule; one declared scale mapping; optional displayed cell values; and zero or one focal row-column pair with the reason it matters. Missing values must be marked as missing, not encoded as zero. The data binding on each cell carries its row ID, column ID, and value; a separate paper underlay carries no data binding.
+
+## Deterministic layout recipe
+
+Use a 1000 × 500 viewBox. Reserve x=40..160 for row labels, y=40..64 for column labels, x=960 as the right edge, and y=420 as the plot floor; leave the lower band for source, legend, and scale key. Start with 4–7 rows and 3–8 columns. Compute cell width and height uniformly from the available plot rectangle after fixed 4px gutters; keep width at least 80px and height at least 36px. If the grid cannot meet both floors, reduce the number of categories through an explicitly named Other group or split into related panels. Right-align row labels in the left gutter, center column labels above cells, and align all grid coordinates to the 4px baseline. Never apply SVG transforms to cells, underlays, labels, or their parent group.
+
+## Encoding rules
+
+Use one monotone ink-opacity ramp for non-focal cells. Declare the domain and transformation in the key; the opacity must never decrease as the value increases. Exclude the focal value when fitting the ramp so an outlier cannot flatten every other cell. Keep the ramp visible at its low end and below the point where cell text loses contrast. Use one accent tint and border for the chosen focal cell. Print exact values inside cells only when they fit; otherwise supply a complete table adjacent to the graphic. If an exact value is required, the key states units and bounds rather than implying that tone is a precise lookup scale.
+
+## Korean behavior
+
+Keep Korean row and column names in Hangul. Use Pretendard for category text and the mono role only for short technical codes or numeric values. Allow two-line wrapping in the label gutters; widen the gutter before shrinking type. Use the common Korean guidance for number grouping, percent signs, units, and mixed Hangul-Latin spacing. Do not rotate Hangul labels to rescue a cramped grid.
+
+## Light, dark, and full variants
+
+Light and dark skins retain identical cell geometry, order, values, and scale. Only semantic color tokens invert; recheck contrast for the darkest non-focal fill and the focal tint in each skin. The full editorial version may add a short framing sentence, source note, and compact conclusion outside the plot. It must not add cells or change the encoding. Keep the legend and source line in the same order across skins.
+
+## Accessibility
+
+Give the SVG a concise title and a description naming the dimensions, measure, period, and focal claim. Never make hue the sole carrier of magnitude: retain the ordered contrast ramp and a text key. Provide a data table for screen readers and for export contexts where cell values matter. Ensure each cell value and axis label meets the text-size and contrast requirements in the accessibility guide.
+
+## Verifier gates
+
+Run scripts/verify-diagram.mjs, the shared diagram verifier for bounds, overlap, rendered clipping, contrast, skin polarity, accessibility, and visible-text checks. Run scripts/verify-type.mjs --type=heatmap; it must confirm the complete Cartesian grid, unique row and column bindings, monotone non-focal opacity, focal count, and printed-value agreement. Review a screenshot at presentation size and confirm that no label is clipped. Then run the humanizer check on visible text.
+
+## Anti-patterns
+
+- One unrelated hue per row or column, which makes category identity compete with the quantity ramp.
+- A rainbow or two-ended ramp for unsigned counts and rates.
+- More than one accent cell or auto-accenting the numeric maximum without checking the story.
+- A continuous gradient key that suggests precision the colors do not provide.
+- A missing row or column that quietly changes the displayed population.
+- A transformed cell whose checked coordinates differ from rendered coordinates.
+- Tiny labels, sideways labels, or numbers that collide with the grid.
+
+## Related references
+
+[Style guide](style-guide.md) · [Output spec](output-spec.md) · [Korean typography](korean-typography.md) · [Accessibility](accessibility.md) · [Office delivery](office-pptx-docx.md) · [Export](export.md) · [Verifier guide](verifier-guide.md) · [Line chart](type-line.md)