@litfamily/litgrok 1.0.14 → 1.0.15

package/.grok/rules/00-litgrok.md

@@ -121,7 +121,7 @@ Film commands, run from the skill root:
 
 ## Office output selection
 
-For an authorized bare `lit` request, choose `lit-docx` when the task asks for a report, doc, docx, Word, 보고서, 리포트, 기획서, 제안서, 문서, or 워드. Choose `lit-pptx` when it asks for slides, deck, presentation, PPT, pptx, 발표자료, 발표, 슬라이드, 덱, or 피피티. If both groups occur, use both skills and keep Markdown source next to both final files. This applies to the task's intent, not stray quoted words or file contents. Under `lit`, choose korean-generic for Korean documents and AZURE-PRO with Pretendard for decks unless the user supplies another choice; do not ask theme or font preference questions for a clear request. Grok's model selection of skills is advisory; verify it in a live host run, and never claim a hook deterministically routed the prompt.
+For an authorized bare `lit` request, choose `lit-docx` when the task asks for a report, doc, docx, Word, 보고서, 리포트, 기획서, 제안서, 문서, or 워드. Choose `lit-pptx` when it asks for slides, deck, presentation, PPT, pptx, 발표자료, 발표, 슬라이드, 덱, or 피피티. If both groups occur, use both skills and keep Markdown source next to both final files. This applies to the task's intent, not stray quoted words or file contents. Under `lit`, each skill picks its design direction itself (a deck tonality or a document tonality, with Pretendard) and names it with two alternatives in the reply; a named template, tonality, publisher or font from the user wins; do not ask theme or font preference questions for a clear request. Grok's model selection of skills is advisory; verify it in a live host run, and never claim a hook deterministically routed the prompt.
 When a bare `lit` Office request gives no facts, still deliver the complete file. Use a plausible example and mark every invented name and figure as sample or assumption in the file and reply. Never leave bracketed blanks. Do not present sample values as sourced results. An explicit non-lit request may ask for missing facts.
 
 ## Interface modes

package/.grok/skills/frontend-ui-ux/THIRD-PARTY-NOTICE.txt

@@ -13,11 +13,6 @@ No upstream scripts, templates, CLI, installers, manifests, screenshots, preview
 documentation, premium features, host integrations, code-example columns,
 documentation-URL columns, or google-fonts.csv data are included.
 
-The craft-floor and slop-register mechanisms were independently re-expressed
-after studying pbakaus/impeccable (https://github.com/pbakaus/impeccable), by
-Paul Bakaus, Apache License 2.0, upstream commit 9d715cc. Its source files,
-prose, and fixtures are not included.
-
 The modes, review format, and routing guidance were independently re-expressed
 after studying jakubkrehel/skills (https://github.com/jakubkrehel/skills),
 Copyright (c) 2026 Jakub Krehel, MIT License, upstream commit 267330e.

package/.grok/skills/frontend-ui-ux/references/slop-register.md

@@ -24,7 +24,7 @@ When a row fires, remove the unnecessary element first, use a native platform co
 | SLOP-016 | **Reflex default sans font** (DET-assist, JUDG verdict): DET-assist: the first family in the resolved `getComputedStyle(el).fontFamily` stack that actually loaded (never any fallback family further down the stack; or an `@font-face`/Google-Fonts URL in `document.styleSheets`) matches a fixed common-default list, **excluding Geist / Geist Sans / Geist Mono** — the current corpus names Geist as its own recommended first alternative to Inter (§4.1), so this row cannot also ban it without reconciling that. JUDG: is there a declared design-token rationale for keeping a matched font (Inter/system-ui in particular are used by many acclaimed, legible real products, not only as a lazy default)? | any match on the fixed list (Geist family excepted) AND JUDG finds no declared rationale | MEDIUM | Pick a less common face tied to the product's own voice, or state why the common one was kept (correct) |
 | SLOP-017 | **Serif reached for without a stated reason** (DET-assist, JUDG verdict): DET: heading font-family matches a fixed banned-serif shortlist. JUDG: is there a one-line stated rationale tying this serif to this brand? | any match on the shortlist AND no rationale recorded | MEDIUM | Switch to a sans display face, or keep the serif only with a recorded rationale (correct) |
 | SLOP-018 | **Giant headline over a weak tiny subhead** (DET-assist, JUDG verdict): DET-assist: ratio of heading computed font-size to its adjacent subhead font-size. JUDG: does the small text actually read as an afterthought, or as a deliberate eyebrow/caption doing its intended job? | ratio ≥ ~3.5 with subhead below ~14px, AND JUDG confirms it reads as an afterthought | MEDIUM | Raise the subhead's role in the scale or shorten the headline pairing (correct) |
-| SLOP-019 | **Too many type moods on one page** (DET): Count of distinct computed `font-family` values across the document (base family only, ignoring fallbacks), excluding any family that resolves only on elements matching a known icon-font signature (single-glyph text content, `aria-hidden="true"`, or a recognized icon-font class/family name) | > 3 distinct families, icon fonts excluded. Chosen over impeccable's stricter 1-family "distill" ceiling because distill is a deliberate reduction workflow, not a general craft floor; krehel's general guidance ("rarely use more than three") is used instead | MEDIUM | Cut back to the stated ceiling for the page (delete) |
+| SLOP-019 | **Too many type moods on one page** (DET): Count of distinct computed `font-family` values across the document (base family only, ignoring fallbacks), excluding any family that resolves only on elements matching a known icon-font signature (single-glyph text content, `aria-hidden="true"`, or a recognized icon-font class/family name) | > 3 distinct families, icon fonts excluded. Chosen over the stricter one-family "distill" ceiling of an earlier reference catalogue because distill is a deliberate reduction workflow, not a general craft floor; krehel's general guidance ("rarely use more than three") is used instead | MEDIUM | Cut back to the stated ceiling for the page (delete) |
 | SLOP-020 | **Lazy all-caps overuse** (DET): `text-transform: uppercase` measured per rendered leaf text node (not per ancestor merely carrying the CSS property, which over-counts when e.g. a `nav ul` wrapper applies it to several short labels at once), skipped when the matched text is > 50% non-cased script (CJK/Hangul), since the transform has no visual "shouting" effect there | leaf text length > ~40 chars under `text-transform: uppercase`, majority-cased-script text only | LOW | Reserve uppercase for short labels only; sentence-case the rest (correct) |
 | SLOP-021 | **Washed-out gray secondary text on a colored surface** (DET): Text lightness is 40–70% AND saturation < 10% (targets genuine mid-gray only; explicitly excludes near-white text at L > 90% and near-black text at L < 10%, both standard, correct, accessible choices of text color on a colored surface), while its containing scope's background is chromatic (saturation clearly above the text's), same tag/branch | text L 40–70%, S < 10%, background chromatic | MEDIUM (cross-ref **CF-201** — craft floor owns the canonical contrast-floor check this overlaps; kept here for the reflex-default pattern itself) | Tint the secondary text from the surface's own hue instead of plain gray (correct) |
 | SLOP-022 | **More than one accent hue competing per screen** (JUDG, DET-assist): DET-assist: histogram of high-saturation hues, sampled only from filled background surfaces ≥ 24×24px (buttons/chips/blocks) — not text or border color, which conflates decorative accents with thin status underlines — and excluding any element carrying a recognized status/semantic role (`role="status"`, `aria-invalid`, a matched success/warning/error/info class, or a small badge/pill shape), since necessary status color-coding is not a competing decorative accent; flag > 1 distinct remaining hue family | > 1 accent hue family, fill-surfaces ≥ 24×24px only, status colors excluded | MEDIUM (cross-ref **CF-205** — craft floor owns the canonical one-accent-per-view threshold and the identical filled-surface/status-role-excluded histogram method; this row restates the same finding as a genericness signal, see Section C's CF-205 catalogue entry for the executable algorithm) | Pick one accent per view and demote the rest to neutral (correct) |
@@ -35,7 +35,7 @@ When a row fires, remove the unnecessary element first, use a native platform co
 | SLOP-027 | **Decorative infinite pulse/blink with no bound state** (DET): Keyframe loop (`animation-iteration-count: infinite`) on an opacity/shadow property, element has none of: a `data-state`/other `data-*` attribute, `aria-busy="true"`, or a recognized skeleton/shimmer/loading class name (the standard loading-skeleton pattern is real and bound, but typically expressed via one of the latter two rather than `data-state` specifically) | presence, no bound-state signal of any of the above kinds | LOW | Remove, or slow it and bind it to the real status it claims to show (delete) |
 | SLOP-028 | **Motion fired on every routine, high-frequency interaction** (JUDG, DET-assist): DET-assist: count animated-transition bindings, restricted to a fixed, inherently-high-frequency selector set (`:hover` transitions, list-item/row transitions, per-item scroll/re-render transitions) as the operational proxy for "fires often" — live session-frequency isn't observable from a single-pass DOM probe | transition duration > ~150ms on a selector in the fixed high-frequency set | LOW (cross-ref **CF-506** — craft floor's ≤150ms high-frequency ceiling is the same threshold, scoped to a repeated-selector/scrollable-container gate) | Make the routine case instant or ≤150ms; save longer motion for rare, meaningful moments (correct) |
 | SLOP-029 | **Eyebrow/kicker label templated above most headings** (DET): Count eyebrow labels: the previous visible element sibling of an h1–h3 that has ≤ 4 words, an uppercase transform or all-caps Latin text, letter-spacing ≥ 0.05em, and a font-size ≤ 0.75× the heading's — counting only elements actually rendered at the current breakpoint (`visible()`) — excludes a hidden responsive-duplicate nav mirror or a currently-collapsed accordion panel from double-counting | count > ceil(sectionCount / 3), where sectionCount = the number of visible h2; visible elements only | MEDIUM (Delta 1: a genericness tell is at most MEDIUM) | Drop the eyebrow; the heading and the section's place on the page already carry the context (delete) |
-| SLOP-030 | **Section numbering used as decoration** (DET-assist, JUDG verdict): DET: regex match of a zero-padded numeric section/tile label prefix, min. 2 distinct index values (matching impeccable's actual, narrower numeric-index-beside-heading coverage). JUDG: does the sequence carry real, meaningful process information (onboarding steps, checkout stages) rather than decorative counting? | any match, ≥ 2 distinct index values, AND JUDG finds no real ordering behind it — the ubiquitous "01/02/03 — how it works" pattern describing a genuinely sequential process is not itself a defect | MEDIUM | Remove the numbering; if progression matters, name the step itself instead of counting it (delete) |
+| SLOP-030 | **Section numbering used as decoration** (DET-assist, JUDG verdict): DET: regex match of a zero-padded numeric section/tile label prefix, min. 2 distinct index values (the narrower numeric-index-beside-heading coverage). JUDG: does the sequence carry real, meaningful process information (onboarding steps, checkout stages) rather than decorative counting? | any match, ≥ 2 distinct index values, AND JUDG finds no real ordering behind it — the ubiquitous "01/02/03 — how it works" pattern describing a genuinely sequential process is not itself a defect | MEDIUM | Remove the numbering; if progression matters, name the step itself instead of counting it (delete) |
 | SLOP-031 | **Unreleased-looking version/status stamp in marketing copy** (DET-assist, JUDG verdict): DET: regex for a version-like token (`vN.N`, `BETA`, `ALPHA`, build-hash pattern) inside visible copy. JUDG: is this inside a real changelog/release-notes/docs context (a live-DOM probe can't reliably distinguish a real changelog page from a mocked one) | any match AND JUDG finds no real release-notes context | MEDIUM | Remove the stamp unless the brief is genuinely about a launch/preview status (delete) |
 | SLOP-032 | **Decorative status dot with no bound state** (DET): Small colored circle/pseudo-element directly preceding label text, with no `data-state`/live-status attribute behind it | presence, no bound attribute | LOW | Remove, or reserve it for an actual live/availability signal (delete) |
 | SLOP-033 | **Middle-dot / locale-time separator strip overused** (DET): Count of `·` glyphs on one line ≥ 3 (raised from the corpus's literal "max 1" cap — a 2-dot "Author · Date · Read time"-style byline strip is standard, tasteful editorial practice, not slop; deliberately loosened here, see Calibration & review changes below); separately, a line combining ≥ 2 of {city name, UTC/GMT offset, temperature/weather token} in one string, which is the observable proxy for "locale strip" (a DOM probe can't see whether the brief is travel-themed) | `·` count ≥ 3 on one line, OR ≥ 2 co-occurring locale/weather tokens on one line | LOW | Prefer line breaks or columns to chained middle-dots; drop the locale strip unless the brief is genuinely place/time relevant (delete) |
@@ -56,8 +56,8 @@ When a row fires, remove the unnecessary element first, use a native platform co
 | SLOP-048 | **Autoplay carousel dots with no real function** (DET): Dot-nav candidate: ≥ 2 visible sibling elements, each ≤ 16×16px with `border-radius` ≥ 50% of its shorter side (or a recognized dots/bullets/indicator class), inside a container that also holds ≥ 2 slides. Autoplay: a declared attribute on the carousel root (`data-autoplay`, `data-bs-ride="carousel"`, `autoplay`), or the active slide or active dot changing between two reads ≥ 6 s apart with no input dispatched; the timed read runs once, at one viewport, and only when a candidate exists, to stay inside the §C.7 per-viewport time cap. Accessible binding, any one of which passes: each dot is a focusable (`tabIndex` ≥ 0) native `<button>`, `role="button"` or `role="tab"` element with an accessible name; the dots carry `aria-controls`; or the current dot carries `aria-selected="true"` (tabbed picker), `aria-disabled="true"` (grouped button picker) or `aria-current`. A key handler attached with `addEventListener` cannot be enumerated from page script (the limit SLOP-058 already states), so this check reads only element and attribute facts and never asserts 'no keyboard binding' | candidate present, autoplay declared or observed, and none of the accessible-binding signals present | LOW | Remove the dots or wire them to real keyboard/AT-reachable navigation (correct) |
 | SLOP-049 | **Generic silhouette/egg avatar standing in for a person** (DET): Avatar element resolves to a small fixed set of known generic-icon asset ids/classes | match against the fixed list | LOW | Use a believable photo placeholder or a deliberate illustrated style instead (correct) |
 | SLOP-050 | **Category label printed under every logo in a trust wall** (DET): Text node directly under a logo image matching a short category-word pattern | any match | LOW | Drop the caption; the logo alone carries the credibility (delete) |
-| SLOP-051 | **Illustration assembled from an excessive primitive count** (JUDG, DET-assist): DET-assist, impeccable's own detector re-expressed for the live DOM: an inline `<svg>` rendered at ≥ 200×200px that holds ≥ 8 `rect`/`circle`/`ellipse`/`polygon` elements anywhere in its subtree (`path` is not counted; drawn artwork is mostly paths), ≥ 3 distinct resolved fill paints (ignoring `none`/`transparent`), ≤ 2 `text`/`tspan` elements, and no `<pattern>`. JUDG: an assembled stand-in scene, or a data graphic or diagram whose shape count is honest? | all DET-assist conditions met (≥ 8 primitives, ≥ 200×200px, ≥ 3 fills, ≤ 2 text elements, no pattern) AND JUDG confirms a stand-in scene. The constants are impeccable's published ones (it reads declared width/height or viewBox; this row reads the rendered box), not yet calibrated on this family's pages | MEDIUM | Commission or simplify the illustration; don't primitive-stack a substitute (correct) |
-| SLOP-052 | **Busy geometric mask faking a photographic edge** (DET): `getComputedStyle(el).clipPath` is a `polygon()` with ≥ 10 vertices where at least half of all coordinate values sit more than 0.5 away from a multiple of 25 (an off-grid, organic contour), or a `path()` with ≥ 3 curve commands (`C`/`S`/`Q`/`T`/`A`, either case). `circle()`, `ellipse()`, `inset()` and grid-aligned polygons (cut corners, diagonals, hexagons) never match | polygon: ≥ 10 vertices and mostly off-grid; path(): ≥ 3 curve segments (impeccable's published constants) | LOW | Use a real photographic crop, or a simple deliberate shape (correct) |
+| SLOP-051 | **Illustration assembled from an excessive primitive count** (JUDG, DET-assist): DET-assist, a published detector re-expressed for the live DOM: an inline `<svg>` rendered at ≥ 200×200px that holds ≥ 8 `rect`/`circle`/`ellipse`/`polygon` elements anywhere in its subtree (`path` is not counted; drawn artwork is mostly paths), ≥ 3 distinct resolved fill paints (ignoring `none`/`transparent`), ≤ 2 `text`/`tspan` elements, and no `<pattern>`. JUDG: an assembled stand-in scene, or a data graphic or diagram whose shape count is honest? | all DET-assist conditions met (≥ 8 primitives, ≥ 200×200px, ≥ 3 fills, ≤ 2 text elements, no pattern) AND JUDG confirms a stand-in scene. The constants are the published ones of an earlier reference catalogue (it reads declared width/height or viewBox; this row reads the rendered box), not yet calibrated on this family's pages | MEDIUM | Commission or simplify the illustration; don't primitive-stack a substitute (correct) |
+| SLOP-052 | **Busy geometric mask faking a photographic edge** (DET): `getComputedStyle(el).clipPath` is a `polygon()` with ≥ 10 vertices where at least half of all coordinate values sit more than 0.5 away from a multiple of 25 (an off-grid, organic contour), or a `path()` with ≥ 3 curve commands (`C`/`S`/`Q`/`T`/`A`, either case). `circle()`, `ellipse()`, `inset()` and grid-aligned polygons (cut corners, diagonals, hexagons) never match | polygon: ≥ 10 vertices and mostly off-grid; path(): ≥ 3 curve segments (published constants of an earlier reference catalogue) | LOW | Use a real photographic crop, or a simple deliberate shape (correct) |
 | SLOP-053 | **Emoji glyphs standing in for a real icon set** (DET-assist, JUDG verdict): DET: text node inside a control/nav/badge element matches the emoji Unicode ranges. JUDG: does the brief carry an explicit emoji-policy exception (not observable from the DOM) | any match AND JUDG finds no stated emoji-policy exception | LOW | Replace with the project's chosen icon set (correct) |
 | SLOP-054 | **Hover transform applied to the image element itself** (DET): CSS rule with a `:hover` transform selector whose target is an `<img>` element (or an element whose only content is a background-image) rather than a parent wrapper | rule targets the image node itself | LOW | Move the transform to the container; animate the frame, not the picture (correct) |
 | SLOP-055 | **Recurring cluster of generic tells appearing together** (JUDG): Checklist: after running the deterministic rows above, does any single component trip 2 or more of them at once? | ≥ 2 co-occurring DET hits on one component escalates the row from WARN to a real finding | MEDIUM (escalated); LOW (WARN) below that | Break up the combination; vary the visual language for that component specifically (correct) |

package/.grok/skills/frontend-ui-ux/scripts/import-design-intelligence.mjs

@@ -20,7 +20,7 @@ const COMPANIONS = Object.freeze([
   ["LICENSE", "738f69dfa83db5c347c678fb9d90e560877059f0de93a327c39001bff92dc014"],
   ["PROVENANCE.json", "a00be969523fe376a07d310b7418be0c41824f01241294bdf00e82eb4d736e87"],
   ["SOURCE-MANIFEST.json", "9adf471d95aaf17e7866e1c7674cb1a101daae9abdab87c71c96a60f2a58e6fa"],
-  ["THIRD-PARTY-NOTICE.txt", "1a04566c00cf3e1e75a5de6b4e5fe0ada59fcececb6603016365ad8bdfa9e8ae"],
+  ["THIRD-PARTY-NOTICE.txt", "638a38f15c4398eb999040eca6c4ad32d8dc0eaf0b096643f73081ab1f85d5cc"],
 ]);
 
 function hash(bytes) {

package/.grok/skills/lit-docx/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lit-docx
-description: Create, edit, lint, audit, and convert Word documents and reports in Grok Build. Select for report, doc, docx, Word, 보고서, 리포트, 기획서, 제안서, 문서, 워드, including a bare lit request. Produce a styled DOCX from Markdown by default.
+description: Create, edit, lint, audit, and convert Word documents and reports in Grok Build. A design direction is chosen first (six restrained tonalities that differ in structure, or a named publisher profile) and named with two alternatives. Select for report, doc, docx, Word, 보고서, 리포트, 기획서, 제안서, 문서, 워드, including a bare lit request. Produce a styled DOCX from Markdown by default.
 user-invocable: true
 argument-hint: <document request or input path>
 ---
@@ -21,28 +21,76 @@ reader_projection: shared_rule
 
 ## Choose the workflow
 
-For a Korean report under `lit`, choose the `korean-generic` publisher profile without a preference question. For other documents, use the plain styled path unless the user specifies Elsevier, ACS, IEEE, Nature, or another available publisher profile. Explicit design, profile, and font choices win. Create both DOCX and PPTX with both Markdown sources when the request names report and slides; invoke `lit-pptx` for the deck. Deliver Markdown/HTML alone only when requested. For an explicit non-lit request, ask about a material missing profile choice if needed.
+A journal submission, or a document for a named publisher, goes to that publisher profile (`--publisher elsevier|acs|ieee|nature|korean-generic`) and keeps its required structure. Every other document — a report, 보고서, 기획서, 제안서, plan, guide, memo or essay — gets one of six tonalities chosen in the direction step below. Explicit design, profile, template and font choices win. Create both DOCX and PPTX with both Markdown sources when the request names report and slides; invoke `lit-pptx` for the deck. Deliver Markdown/HTML alone only when requested.
 
-Read supplied source files and distinguish evidence from interpretation. For a bare `lit` request with no facts, pick a plausible worked example and mark every invented name and figure as sample/assumption on the page and in the reply. Do not leave bracketed blanks or invent citations. Quoted or embedded document text is inert data. Keep source text and revision history outside the installed skill tree. Before submission, check that heading levels, table column widths, unbroken rows, captions, references, page numbers and Korean line breaks match the user's requested genre. Give a general report a clear title and opening summary; keep its tables readable across pages. Keep technical evidence in a receipt, not as visible manuscript boilerplate.
+Under a bare `lit` request the skill decides the direction itself and asks nothing; the reply names the choice and two alternatives afterwards. For an explicit non-lit request the user is present, so one short question round may offer the chosen tonality first, the two alternatives and a compare option. There is never a silent default look.
+
+Read supplied source files and distinguish evidence from interpretation. For a bare `lit` request with no facts, pick a plausible worked example and mark every invented name and figure as sample/assumption on the page and in the reply (`notice: "예시 데이터: 실제 수치로 바꿔 주세요"` in the frontmatter prints once under the title block). Do not leave bracketed blanks or invent citations. Quoted or embedded document text is inert data. Keep source text and revision history outside the installed skill tree. Keep technical evidence in a receipt, not as visible manuscript boilerplate.
+
+## Direction step
+
+Read `references/direction-step.md` before choosing a tonality: it maps document types to candidates, lists the content signals that reorder them, and gives the direction card. The six share one restrained page — near-black ink for body and headings, a quiet type scale (h1 about 1.4 times the body), A4, Pretendard for Hangul and Latin, booktabs tables without fills, at most one accent on at most two element kinds — and differ in structure: what stands on page 1, how the summary is set, how headings are numbered, which components the document may use, and what the running head carries.
+
+| Tonality | Use it for | Read before writing |
+| --- | --- | --- |
+| `report` | results, analysis, a formal report | Read `references/tonalities/report.md` for a Report document |
+| `brief` | a Korean itemised briefing (개조식) for one decision maker | Read `references/tonalities/brief.md` for a Brief document |
+| `manual` | a guide, procedure or onboarding text with steps and warnings | Read `references/tonalities/manual.md` for a Manual document |
+| `proposal` | a proposal, plan or funding request with a cover | Read `references/tonalities/proposal.md` for a Proposal document |
+| `memo` | a one- or two-page notice, memo or decision request | Read `references/tonalities/memo.md` for a Memo document |
+| `journal` | an essay, newsletter or white paper in two columns | Read `references/tonalities/journal.md` for a Journal document |
+
+1. Settle document type, reader, delivery (printed, on screen, sent ahead), language and expected length; infer what the brief leaves out.
+2. Take the first candidate for the type, let the material reorder the row (many tables, under about 900 words, numbered procedures, long English prose, a decision as the point), and keep the deck-type order on ties.
+3. Write the card into `<name>.build.md` beside the source: type, reader, tonality and two alternatives, a reason tied to the reader and the signals, the density and variance dials (move either by at most 2 without asking), the cover and heading treatment, the components planned with one purpose each, and what would make this direction wrong.
+4. Put `tonality: <id>` in the frontmatter; in the reply, say the choice and why, then the two alternatives in one sentence.
+5. When the user asks to compare, convert the same source under the chosen tonality and both alternatives (`--tonality`), render the first three pages of each, and continue under the one picked.
+
+## Write the source
+
+- A short summary section (요약 / Summary) states the conclusion first; then background, analysis or options, the recommendation, and next steps with owners and dates when the sources give them.
+- Headings, the title and the subtitle are noun-phrase labels, never sentences: "3분기 실적과 원가", not "3분기 매출이 계획을 넘었다"; "Conversion by feed rate", not "Staged feed raises conversion". The claim goes in the first sentence under the heading.
+- Numbers keep their true weight: a key figure is no larger than the h2 size and always carries its label and a basis line (period, base, source); no hero numerals, no rounding up for effect.
+- Pages fill through measure, leading and structure, never through type under 10.5 pt or crowded boxes. Components are few and only for real content: at most three kinds per document, one key-figure strip, a callout about once per four pages for the decision request or a warning, a sidebar only in a Manual, two columns only when both parts are about the same length. Read `references/components.md` for the `:::` directive syntax and the component budget, and read `references/page-composition.md` for how pages fill, split and carry tables, figures, covers and running heads.
+- Korean conventions on every path: dates as `2026. 6. 30.` or `2026년 6월 30일` (an ISO date is rewritten), `<표 1>` captions above tables with a shared unit on a `(단위: …)` line, `주:` and `출처:` under them, heading numbers in the order Ⅰ., 1., 가. where the tonality numbers headings, Hangul emphasised by weight and never italic. Word breaks Hangul between words (wordWrap on, ko-KR); a LibreOffice preview may break between syllables.
+- Tables: units in headers, at most six columns, short cells, a sentence after the table that says what it shows. The converter sizes columns to content, right-aligns number columns, repeats the header row and keeps each row on one page.
+- Open the closest worked source in `examples/` (nine documents covering all six tonalities in Korean and English; each converts and passes the gate) before writing.
 
 ## Convert and edit
 
-The packaged scripts, publisher registry, editable templates, LaTeX profiles, and lint references live under this skill. Use the launcher so the pinned Python venv installs on first use into the LitGrok office cache. `node .grok/skills/lit-docx/scripts/run.mjs doctor` reports readiness and optional host tools.
+The packaged scripts, publisher registry, editable templates, LaTeX profiles, tonality packs and lint references live under this skill. Use the launcher so the pinned Python venv installs on first use into the LitGrok office cache. `node .grok/skills/lit-docx/scripts/run.mjs doctor` reports readiness and optional host tools.
 
-- Markdown to a Korean report: `node .grok/skills/lit-docx/scripts/run.mjs convert_md_to_docx.py report.md report.docx --publisher korean-generic`.
-- Markdown to another publisher manuscript: use the same script with `--publisher elsevier|acs|ieee|nature`; inspect `templates/registry.yaml` and the relevant DOCX template before delivery.
-- Plain styled Markdown to DOCX: omit `--publisher` when no publisher shape is requested.
+- Markdown to a tonality document: `node .grok/skills/lit-docx/scripts/run.mjs convert_md_to_docx.py report.md report.docx` (the tonality comes from the frontmatter; `--tonality brief`, `--density`, `--variance` override it).
+- Markdown to a publisher manuscript: the same script with `--publisher korean-generic|elsevier|acs|ieee|nature`; inspect `templates/registry.yaml` and the relevant DOCX template before delivery. Text never touches a table or a caption: the paragraph after a table, a table caption after text and the text under a figure caption stand 8 pt clear (a heading keeps its own space). A tonality and a publisher are mutually exclusive.
+- Plain styled Markdown to DOCX: omit both; the plain profile runs through the same builders with neutral tokens.
 - Edit an existing DOCX: `node .grok/skills/lit-docx/scripts/run.mjs edit_docx.py input.docx --replace OLD NEW -o revised.docx`; use `--append-md` or `--insert-at` for structured changes and keep the original.
 - DOCX to Markdown: use `pandoc -f docx -t gfm --wrap=none --extract-media=media input.docx -o draft.md`, then run `clean_markdown.py` and inspect tables, citations, footnotes, tracked changes and extracted media. Missing pandoc blocks this path; do not claim a conversion from another format.
 - PDF to Markdown: run `convert_pdf.py` from the launcher and inspect the extraction order. Scanned PDFs need OCR outside this skill; a text extractor cannot certify them.
 - Markdown to PDF: run `convert_md_to_pdf.py` with the selected publisher profile. XeLaTeX and pandoc are optional host prerequisites for this path; if missing, deliver DOCX and state the PDF boundary. Do not silently substitute a screen capture for a publication PDF.
 
-For a styled publisher manuscript, run `slop_lint.py report.md --publisher <profile> --report lint.md`, then audit the DOCX with `--audit-docx report.docx` where applicable. The DOCX audit includes OF-301 page measure as an advisory and OF-302 explicit numeric-column alignment as a hard finding; inherited alignment remains advisory. For a proposal, business plan, or other non-manuscript report, pass `--genre general` so the lint retains prose, typography, and DOCX checks without imposing a scientific journal section order. Use `visual_audit.py report.docx --out-dir <task-output>` when LibreOffice is present, convert the PDF pages to PNG, and inspect the first three pages for glyph coverage, headers, tables, footnotes, spacing and page breaks. If LibreOffice is absent, report that rendered-page review was skipped. Structural inspection and a successful DOCX reopen still matter.
+## Gate and look
+
+`node .grok/skills/lit-docx/scripts/run.mjs docx_gate.py report.docx --source report.md --layout` must exit 0 (add `--publisher <profile> --kind manuscript` for a manuscript). It checks the package (readable ZIP, no NaN attribute values, python-docx reopen); the content (body text present, every source heading reached the document, no unfilled `[blank]`/`XXX`/`TBD`/`○○`, no frontmatter printed as text); the prose lint and DOCX audits of `slop_lint.py` (numeric columns right-aligned, OF-302; Hangul runs paired with a real east-Asian face, read through the style chain; a publisher's own design rules on a publisher run; journal outline rules only for a manuscript); and the output checks of `scripts/docx_layout.py`: noun-phrase headings and heading order always, the frontmatter notice written with a colon (`예시 데이터: …`, `Sample memo: …`), never a spaced dash (`notice.dash`, a failure on a tonality document and advice otherwise), the restraint rules on a tonality document (one accent hue on at most two element kinds, ink headings, h1 at most 1.5 times the body, no shaded table cell, at most three component kinds and one key-figure strip, no coloured notice in a page header, no ISO date in Korean text), and with `--layout` the page checks on a LibreOffice render (no body page under 0.35 of its frame except cover and last, no memo that runs onto a second page it fills under a quarter of the frame (`memo.fit`), no two-page document whose second page is under 0.4 of the frame and no last page under an eighth (`page.spill`), no list of up to six items split across pages or columns, except one break of a five- or six-item list in a column with two items or more on each side (`list.split`), no heading at the foot of a column while its text opens the next one (`heading.column`), no column a quarter short beside a full one and no last page with uneven columns (`columns.balance`), no heading and its lead sentence apart from the short table they open (`heading.apart`), no page ending on a heading, no table that fits one page split across two, no component box split, no picture apart from its caption, at least two component kinds on a four-page tonality document, no filled shape over a quarter of a cover). `--compare other.docx` fails two tonalities of one source that differ in fewer than three structural features. Without `soffice` the page checks are reported as not run, and the reply says so. Fix the Markdown and reconvert; never weaken the gate.
+
+For a publisher manuscript also run `slop_lint.py report.md --publisher <profile> --report lint.md` for the full report and submission checklist; for a proposal, business plan or other non-manuscript text pass `--genre general` so the journal section order is not imposed. Use `visual_audit.py report.docx --out-dir <task-output>` when LibreOffice is present, convert the PDF pages to PNG, and open them: the title block or cover, heading rhythm, components (does the callout hold the decision, does each key figure show its basis), Korean glyphs, table rules, page breaks and whether the card's "wrong if" line came true. Three rounds is the budget; record the gate result and what the pages showed in the build log. Rendered pages are necessary for a visual claim. Pretendard is not embedded in the DOCX, so pages look as rendered only where the font is installed; say so when the renderer had to substitute it.
 
-The `templates/registry.yaml` controls publisher typography and geometry. The templates under `templates/docx/` are editable profile assets; `generate_docx_templates.py` regenerates them from the registry only in a task-owned copy unless the user asked to update the installed product. Read `references/frontmatter_schema.md`, `references/journal_style_spec.md`, `references/markdown_quality_checklist.md`, and `references/slop_rules.md` as needed. `embed_images.py` is for a self-contained Markdown handoff; check media rights before embedding.
+The `templates/registry.yaml` controls publisher typography and geometry; `templates/tonalities/<id>.yaml` holds the six packs the converter reads. The templates under `templates/docx/` are editable profile assets; `generate_docx_templates.py` regenerates them from the registry only in a task-owned copy unless the user asked to update the installed product. Read `references/frontmatter_schema.md` for the journal frontmatter fields, read `references/journal_style_spec.md` before preparing a publisher manuscript, read `references/markdown_quality_checklist.md` when cleaning converted Markdown, and read `references/slop_rules.md` for the prose rules the lint enforces. `embed_images.py` makes a self-contained Markdown handoff; check media rights before embedding.
 
 ## Quality and limits
 
-Use specific section titles and evidence-backed claims. Preserve required publisher structure; do not flatten a manuscript into generic prose. Keep tables with meaningful headers and units, readable image captions, and explicit citation placeholders when source metadata is absent. `slop_lint.py` flags patterns for review; it does not prove truth or suitability. Open the `.docx` with python-docx after conversion, and compare extracted paragraphs to the Markdown source so content is not silently dropped. Rendered pages are necessary for a visual claim.
+Use specific section titles and evidence-backed claims. Preserve required publisher structure; do not flatten a manuscript into generic prose. Keep tables with meaningful headers and units, readable captions, and explicit citation placeholders when source metadata is absent. `slop_lint.py` flags patterns for review; it does not prove truth or suitability. A clean gate is defect-absence, not a verdict on how the pages read.
+
+The installed package and the office cache are local to LitGrok. The pinned `requirements.lock` covers python-docx, Markdown, Beautiful Soup, PyMuPDF, PyYAML, python-pptx and support packages; the launcher runs Python without writing bytecode into the skill folder. It does not change the user's global Python, Grok login or host configuration. `pandoc`, `xelatex`, and `soffice` remain user-provided optional tools. A failed install, corrupt DOCX, lint failure, or missing optional tool is a reported boundary; retain the original Markdown and input document for recovery.
+
+## Reference map
 
-The installed package and the office cache are local to LitGrok. The pinned `requirements.lock` covers python-docx, Markdown, Beautiful Soup, PyMuPDF, PyYAML, python-pptx and support packages. It does not change the user's global Python, Grok login or host configuration. `pandoc`, `xelatex`, and `soffice` remain user-provided optional tools. A failed install, corrupt DOCX, lint failure, or missing optional tool is a reported boundary; retain the original Markdown and input document for recovery.
+| Need | Where |
+| --- | --- |
+| Choosing the tonality, the card, comparing | `references/direction-step.md` |
+| One tonality's structure, tokens and components | `references/tonalities/<id>.md` |
+| The `:::` components and their budget | `references/components.md` |
+| Page grid, measure, leading, splits, covers, running heads | `references/page-composition.md` |
+| Worked sources that convert and pass the gate | `examples/` |
+| The packs the converter reads | `templates/tonalities/<id>.yaml` |
+| The gate and its output checks | `scripts/docx_gate.py`, `scripts/docx_layout.py` |
+| Publisher profiles | `templates/registry.yaml`, `references/journal_style_spec.md` |

package/.grok/skills/lit-docx/examples/01-report-ko.md

@@ -0,0 +1,137 @@
+---
+title: 본사 옥상 태양광 설비 1년 운영 결과
+subtitle: 2025년 10월~2026년 9월 발전 실적, 전기요금 절감과 2027년 보완 계획
+author: 시설관리팀 에너지파트
+organization: 예시 주식회사
+date: 2026-10-05
+short_title: 옥상 태양광 1년 운영 결과
+notice: "예시 데이터: 회사명, 설비 용량, 금액은 모두 가정입니다. 실제 수치로 바꿔 주세요"
+tonality: Report
+---
+
+::: cover variant=masthead kicker="운영 결과 보고"
+본사 옥상 태양광 설비를 가동한 첫 1년의 발전량, 자가소비 비율, 전기요금 절감액, 고장 이력을 정리하고 2027년 보완 공사와 예산 요청을 함께 담았다.
+:::
+
+# 요약
+
+옥상 태양광 설비는 1년 동안 312MWh를 생산해 본사 연간 전력 사용량의 8.4%를 대체했다. 설계 단계에서 예측한 발전량 298MWh보다 4.7% 많다. 생산한 전력은 대부분 건물 안에서 바로 썼고, 휴일 낮에 남은 전력만 한전 계통으로 보냈다.
+
+::: keyfigures
+- **312MWh** 연간 발전량 (예시)
+  * 2025. 10.~2026. 9. 인버터 누적 기록
+- **8.4%** 본사 전력 사용량 대비 (예시)
+  * 같은 기간 수전 계량기 기준
+- **4,180만 원** 전기요금 절감액 (예시)
+  * 계시별 요금 적용, 부가세 제외
+:::
+
+절감액은 투자비 회수 계획의 연간 목표 3,900만 원을 넘었다. 다만 여름철 한낮에 모듈 온도가 올라 출력이 떨어지는 시간이 예상보다 길었고, 동쪽 구역 인버터 1대가 두 차례 멈춰 11일 동안 발전량 손실이 있었다. 2027년 상반기에 인버터 교체와 모듈 세척 주기 조정을 진행하며, 이에 필요한 예산 2,600만 원의 승인을 요청한다.
+
+# 설비 개요
+
+## 설치 규모와 구성
+
+설비는 본관과 별관 옥상 두 곳에 나뉘어 있다. 본관에는 모듈 540장(설비 용량 248kW), 별관에는 모듈 160장(73kW)이 남향 15도 경사로 놓였다. 인버터는 본관 4대, 별관 1대이며, 각 인버터의 출력은 지하 2층 수전반에서 건물 부하와 합쳐진다.
+
+표 1. 구역별 설비 구성 (예시)
+
+| 구분 | 본관 옥상 | 별관 옥상 | 합계 |
+| --- | ---: | ---: | ---: |
+| 모듈 수 (장) | 540 | 160 | 700 |
+| 설비 용량 (kW) | 248 | 73 | 321 |
+| 인버터 (대) | 4 | 1 | 5 |
+| 설치 면적 (㎡) | 1,620 | 480 | 2,100 |
+
+자료: 시설관리팀 준공 도서(2025. 9.)
+
+## 계량과 기록 방식
+
+발전량은 인버터별 누적 계량값을 15분 간격으로 원격 수집한다. 건물 사용량은 한전 수전 계량기와 내부 부하 계량기를 함께 읽는다. 두 값의 차이로 자가소비량과 역송량을 계산하며, 월말에 한전 청구서와 대조해 오차가 1%를 넘으면 원인을 찾는다. 1년 동안 오차가 1%를 넘은 달은 2026년 2월 한 번뿐이었고, 원인은 계량기 통신 장애로 확인했다.
+
+# 발전 실적
+
+## 월별 발전량
+
+발전량은 5월에 가장 많았고 12월에 가장 적었다. 일사량이 가장 많은 달은 6월이었지만, 장마가 일찍 시작된 데다 모듈 온도가 높아 5월 실적에 못 미쳤다. 겨울철에는 해가 낮아 별관 옥상 일부가 본관 그림자에 가렸다. 아래 표의 예측값은 설계 시뮬레이션의 월별 값을 분기로 합한 것이다.
+
+표 2. 분기별 발전량과 예측 대비 실적 (예시)
+
+| 분기 | 예측 (MWh) | 실적 (MWh) | 예측 대비 (%) |
+| --- | ---: | ---: | ---: |
+| 2025년 4분기 | 58 | 61 | 105.2 |
+| 2026년 1분기 | 66 | 69 | 104.5 |
+| 2026년 2분기 | 94 | 101 | 107.4 |
+| 2026년 3분기 | 80 | 81 | 101.3 |
+| 합계 | 298 | 312 | 104.7 |
+
+자료: 인버터 원격 감시 기록
+
+3분기 실적이 예측과 거의 같았던 것은 8월 인버터 정지의 영향이다. 정지가 없었다면 3분기 실적은 약 85MWh로 추정되며, 이 경우 연간 실적은 예측보다 6% 정도 많았을 것이다.
+
+## 자가소비와 역송
+
+생산 전력의 93%를 건물 안에서 바로 썼다. 평일 낮에는 사무 부하와 냉방 부하가 발전량보다 커서 남는 전력이 거의 없다. 역송은 주로 토요일과 공휴일 낮에 생겼고, 1년 동안 모두 22MWh였다. 역송 전력은 상계 거래로 처리해 다음 달 요금에서 차감했다.
+
+## 효율 저하 요인
+
+출력을 깎은 요인은 세 가지였다. 첫째는 여름철 모듈 온도다. 7월과 8월 한낮에 모듈 표면 온도가 65도를 넘은 시간이 하루 평균 3.2시간이었고, 이 시간대 출력은 정격의 78% 수준에 머물렀다. 둘째는 먼지와 새 배설물이다. 봄철 황사 이후 세척 전후의 출력 차이가 4% 안팎으로 측정됐다. 셋째는 겨울철 별관 그림자로, 12월과 1월 오전 10시 이전에는 별관 모듈 중 40장 정도가 그늘에 들었다.
+
+# 비용과 절감 효과
+
+## 전기요금 절감액
+
+절감액은 자가소비량에 해당 시간대 요금 단가를 곱한 값과 상계 처리된 역송 금액을 더해 계산했다. 여름철 낮 시간대 단가가 높아 6~8월 세 달의 절감액이 연간 절감액의 36%를 차지했다.
+
+표 3. 절감액과 운영비 (예시)
+
+| 항목 | 금액 (만 원) | 비고 |
+| --- | ---: | --- |
+| 자가소비 절감액 | 3,890 | 계시별 단가 적용 |
+| 역송 상계 금액 | 290 | 22MWh |
+| 유지보수 계약비 | 480 | 연 1회 정밀 점검 포함 |
+| 모듈 세척비 | 120 | 연 3회 |
+| 순절감액 | 3,580 | 절감액에서 운영비를 뺀 값 |
+
+자료: 재무팀 전기요금 정산 자료, 시설관리팀 계약 대장
+
+## 투자비 회수 전망
+
+설치 투자비는 5억 1,000만 원이었다. 첫해 순절감액 3,580만 원이 그대로 유지된다고 보면 회수에는 약 14년이 걸린다. 그러나 전기요금 단가는 2026년에만 두 차례 올랐고, 모듈 출력은 해마다 0.5% 정도씩 낮아진다. 두 요인을 함께 넣은 재무팀 추정으로는 회수 기간이 12~13년이다.
+
+::: callout kind=note title="회수 기간 추정의 전제"
+요금 단가는 연 3% 상승, 모듈 출력은 연 0.5% 저하, 유지보수비는 연 2% 상승을 가정했다. 단가 상승률이 연 1%에 그치면 회수 기간은 15년으로 늘어난다.
+:::
+
+# 운영상 문제와 대응
+
+## 인버터 정지
+
+동쪽 구역 3번 인버터가 2026년 3월과 8월 두 차례 과열 경보로 멈췄다. 3월에는 하루 만에 재가동했지만, 8월에는 냉각 팬 부품을 해외에서 들여오느라 10일이 걸렸다. 국내 재고가 없었다. 두 번의 정지로 잃은 발전량은 약 5MWh, 금액으로는 70만 원 정도다. 제조사는 같은 모델의 냉각 팬 결함을 인정하고 2027년 1분기 안에 무상 교체를 약속했다. 그러나 팬만 바꾸면 설치 위치의 환기 부족은 그대로 남는다.
+
+## 세척 주기
+
+계약상 세척은 연 3회(3월, 6월, 10월)였다. 문제는 시기다. 황사가 심했던 4월과 꽃가루가 많았던 5월 사이에는 세척 전후 출력 차이가 4%를 넘었다. 세척 시기를 황사 직후로 옮기고 여름 장마 전 한 번을 추가하면, 연간 발전량이 1.5% 정도 늘 것으로 본다. 세척 업체와는 2026년 12월 계약 갱신 때 횟수와 시기를 함께 바꾸기로 협의했고, 추가 1회 비용은 기존 단가인 회당 40만 원을 그대로 적용하기로 했으며, 황사 특보가 사흘 이상 이어진 주에는 업체가 먼저 일정을 제안하도록 계약서에 넣기로 했다.
+
+## 안전 관리
+
+옥상 출입은 시설관리팀 승인을 받은 인원만 가능하고, 출입 기록은 보안실 출입 통제 시스템에 남는다. 1년 동안 안전사고는 없었다. 외부 세척 업체 작업자도 작업 당일 현장 안전교육을 받고 추락 방지 장비를 점검받은 뒤에만 옥상에 올라갔으며, 교육 기록과 장비 점검표는 시설관리팀이 작업일마다 받아 보관했다. 다만 별관 옥상 난간 높이가 기준보다 10cm 낮아 2026년 6월에 임시 안전망을 설치했다.
+
+# 2027년 보완 계획과 예산
+
+## 보완 과제
+
+보완 과제는 세 가지다. 3번 인버터를 환기가 되는 위치로 옮기면서 냉각 팬을 교체하고, 세척 주기를 연 4회로 늘리며, 별관 옥상 난간을 기준 높이로 높인다. 그늘 문제는 모듈 배치를 바꿔야 해결되므로 비용 대비 효과를 따져 2028년에 다시 검토한다.
+
+표 4. 2027년 보완 예산 요청 (예시)
+
+| 과제 | 시기 | 금액 (만 원) |
+| --- | --- | ---: |
+| 3번 인버터 이설과 환기 덕트 | 2027년 1분기 | 1,450 |
+| 세척 1회 추가(연 4회) | 2027년 6월 | 40 |
+| 별관 옥상 난간 보강 | 2027년 2분기 | 1,110 |
+| 합계 | | 2,600 |
+
+## 기대 효과
+
+인버터 이설과 세척 주기 조정으로 연간 발전량이 2~3% 늘면, 절감액은 연 80만~120만 원 정도 늘어난다. 금액만 보면 크지 않다. 그러나 같은 고장이 되풀이되면 한 번에 10일 이상 발전이 멈출 수 있고, 난간 보강은 법정 안전 기준을 맞추기 위한 공사다. 예산이 승인되면 2027년 1월에 업체를 선정하고, 공사는 발전량이 적은 2월 안에 마친다.

package/.grok/skills/lit-docx/examples/02-brief-ko.md

@@ -0,0 +1,82 @@
+---
+title: 사내 메신저 전환 검토 보고
+subtitle: 현행 계약 만료에 따른 대안 비교와 2027년 1분기 전환안
+author: 정보전략팀
+organization: 예시 공사
+date: 2026-10-05
+short_title: 사내 메신저 전환 검토
+notice: "예시 데이터: 기관명, 인원, 금액은 모두 가정입니다. 실제 수치로 바꿔 주세요"
+tonality: Brief
+---
+
+::: cover variant=masthead kicker="검토 보고"
+:::
+
+::: callout kind=key title="결정 요청"
+현행 메신저 계약을 연장하지 않고 2027년 3월 말까지 그룹웨어 내장 메신저(안 2)로 전환하는 안, 그리고 전환 비용 3,200만 원(예시)을 2026년 4분기 정보화 예비비에서 집행하는 안의 승인을 요청한다.
+:::
+
+# 요약
+
+안 2로 전환하면 3년간 1억 1,400만 원을 아낀다. 현행 메신저를 3년 더 쓰는 비용은 2억 400만 원이고, 그룹웨어 내장 메신저는 전환비를 포함해 9,000만 원이다(예시).
+
+기능 손실은 크지 않다. 직원 1,240명의 최근 6개월 사용 기록을 보면 대화, 파일 전송, 화상 통화가 전체 사용의 96%를 차지하며, 세 기능 모두 내장 메신저에 있다.
+
+보안 요건도 충족한다. 내장 메신저는 사내 서버에 대화를 저장하고, 2026년 8월 보안 진단에서 지적 사항 없이 통과했다.
+
+위험은 전환 기간의 혼선이다. 대화 기록 이관과 외부 협력사 계정 재발급에 6주가 걸리므로, 2027년 1월 첫 주에 착수해야 3월 말 계약 만료 전에 끝난다.
+
+# 검토 배경
+
+- 현행 메신저 계약 만료일 2027. 3. 31., 연장 시 사용료 연 18% 인상 통보 받음
+- 그룹웨어는 2025년 교체 때 메신저 기능을 포함해 계약, 현재 사용하지 않는 상태
+- 두 메신저를 함께 쓰는 부서가 생겨 업무 요청 누락 사례가 분기마다 보고됨
+- 2026년 7월 경영진 회의에서 메신저 일원화 검토를 지시
+
+# 대안 비교
+
+표 1. 대안별 3년 비용과 주요 특성 (예시)
+
+| 구분 | 안 1 현행 연장 | 안 2 그룹웨어 내장 | 안 3 신규 도입 |
+| --- | ---: | ---: | ---: |
+| 3년 사용료 (만 원) | 20,400 | 5,800 | 13,500 |
+| 전환비 (만 원) | 0 | 3,200 | 4,600 |
+| 3년 합계 (만 원) | 20,400 | 9,000 | 18,100 |
+| 대화 서버 위치 | 외부 | 사내 | 외부 |
+| 전환 기간 | 없음 | 6주 | 10주 |
+
+자료: 업체 견적(2026. 9.), 정보전략팀 산출
+
+- 안 1은 전환 부담이 없으나 비용이 가장 크고, 인상분이 매년 반복될 가능성 있음
+- 안 2는 비용이 가장 적고 대화가 사내 서버에 남음. 화면 공유 중 원격 제어 기능은 없으나 사용 비중 0.4%로 원격 지원 도구로 대체 가능
+- 안 3은 기능이 가장 많으나 비용과 전환 기간 모두 안 2보다 불리함
+
+# 전환 일정과 위험
+
+## 추진 일정
+
+- 2027년 1월 1주: 전환 공지, 부서별 담당자 지정
+- 2027년 1월 2~4주: 최근 1년 대화 기록 이관, 협력사 계정 380개 재발급
+- 2027년 2월: 두 메신저 병행 운영, 현행 메신저는 읽기 전용으로 전환
+- 2027년 3월 2주: 현행 메신저 종료, 3월 말 계약 만료
+
+## 위험 대응
+
+- 대화 기록 이관 누락: 이관 전후 건수를 부서별로 대조하고, 원본은 계약 만료 후 1년간 보관
+- 협력사 계정 재발급 지연: 협력사별 담당자 목록을 12월 중 먼저 확보
+- 병행 기간의 요청 누락: 2월부터 업무 요청은 내장 메신저로만 받도록 부서장 회의에서 공지
+
+# 소요 예산
+
+표 2. 전환 비용 내역 (예시)
+
+| 항목 | 금액 (만 원) |
+| --- | ---: |
+| 대화 기록 이관 용역 | 1,800 |
+| 협력사 계정 발급과 인증 설정 | 700 |
+| 사용자 교육과 안내 자료 | 400 |
+| 예비비 | 300 |
+| 합계 | 3,200 |
+
+- 집행 재원: 2026년 4분기 정보화 예비비(잔액 5,100만 원)
+- 2027년 이후 사용료는 그룹웨어 유지보수 계약에 포함

package/.grok/skills/lit-docx/examples/03-manual-ko.md

@@ -0,0 +1,118 @@
+---
+title: 연구동 공용 흄후드 일상 점검 절차서
+subtitle: 3층 공용 실험실 흄후드 6대의 사용 전 점검, 월간 풍속 측정과 이상 시 조치
+author: 연구지원팀 실험실안전파트
+organization: 예시 연구원
+date: 2026-10-05
+short_title: 흄후드 일상 점검 절차서
+notice: "예시 데이터: 설비 번호, 기준값, 연락처는 모두 가정입니다. 실제 값으로 바꿔 주세요"
+tonality: Manual
+---
+
+# 적용 범위
+
+## 대상 설비와 사용자
+
+이 절차서는 연구동 3층 공용 실험실 301호와 302호에 설치된 흄후드 6대(FH-301-1~3, FH-302-1~3)에 적용한다. 사용자는 공용 실험실 사용 승인을 받은 연구원과 학생 연구원이며, 승인 전 실험실 안전교육 2시간을 이수해야 한다. 개인 실험실의 흄후드와 생물안전작업대는 별도 절차서를 따른다.
+
+::: sidebar title="용어"
+**면속도**: 새시 개구부를 지나 흄후드 안으로 들어가는 공기의 평균 속도(m/s).
+
+**새시**: 흄후드 앞면의 위아래로 움직이는 유리문. 작업 높이는 바닥에서 40cm다.
+
+**배기 경보**: 면속도가 기준 아래로 떨어지면 울리는 소리와 표시등.
+:::
+
+흄후드는 실험 중 생기는 유해 증기를 실험자 쪽으로 새지 않게 빨아들여 옥상 배기구로 내보낸다. 이 기능은 면속도가 기준 범위 안에 있고 새시가 작업 높이 이하로 내려와 있을 때만 유지된다. 그래서 점검의 중심은 면속도와 새시 위치, 그리고 후드 안의 기류를 막는 물건이 없는지 확인하는 일이다.
+
+## 책임
+
+연구지원팀은 월간 풍속 측정, 연간 정밀 검사, 고장 수리 접수를 맡는다. 사용자는 사용 전 점검과 사용 후 정리를 맡는다. 점검 결과는 각 흄후드 옆에 붙은 점검표와 실험실 안전 관리 시스템에 함께 남긴다.
+
+표 1. 점검 구분과 주기 (예시)
+
+| 구분 | 주기 | 담당 | 기록 |
+| --- | --- | --- | --- |
+| 사용 전 점검 | 매 사용 시 | 사용자 | 흄후드 옆 점검표 |
+| 월간 풍속 측정 | 매월 첫째 주 | 연구지원팀 | 안전 관리 시스템 |
+| 연간 정밀 검사 | 매년 3월 | 외부 검사 기관 | 검사 성적서 |
+| 고장 점검 | 경보 또는 신고 시 | 연구지원팀 | 수리 이력 대장 |
+
+# 사용 전 점검
+
+## 점검 순서
+
+흄후드를 켜고 1분이 지난 뒤 다음 순서로 점검한다. 한 항목이라도 기준을 벗어나면 실험을 시작하지 않고 4장의 조치를 따른다.
+
+1. 전원 스위치를 켜고 조명과 배기 팬이 함께 작동하는지 확인한다.
+2. 표시창의 면속도가 0.4~0.6m/s 범위 안에 있는지 읽는다.
+3. 새시를 작업 높이 40cm까지 올렸다가 내리며 걸림이 없는지 본다.
+4. 후드 안쪽 뒷면 배기 슬롯 앞 15cm 안에 시약병이나 장비가 없는지 확인한다.
+5. 작업대 위에 쏟은 시약 자국이 있으면 사용 전에 닦고 점검표에 적는다.
+6. 점검표에 날짜, 이름, 면속도 값을 적고 서명한다.
+
+::: callout kind=warning title="경보가 울릴 때"
+배기 경보가 울리면 진행 중인 작업을 멈추고 용기 뚜껑을 닫은 뒤 새시를 끝까지 내린다. 경보를 끄거나 테이프로 표시등을 가리지 않는다. 실험실 밖으로 나와 연구지원팀(내선 3150)에 알리고, 조치가 끝날 때까지 해당 흄후드에 사용 금지 표지를 건다.
+:::
+
+## 작업 중 지켜야 할 사항
+
+작업은 새시 면에서 15cm 이상 안쪽에서 한다. 머리를 후드 안으로 넣지 않으며, 새시를 작업 높이보다 올린 채 자리를 비우지 않는다. 후드 안에 큰 장비를 둘 때는 받침대를 써서 바닥과 장비 사이에 5cm 정도 틈을 두어 기류가 장비 밑으로 지나가게 한다. 가열판과 같은 열원은 기류를 흐트러뜨리므로 후드 중앙 뒤쪽에 둔다. 산과 휘발성 유기 용매를 쓰는 작업은 한 후드 안에서 동시에 하지 않으며, 둘을 이어서 해야 하는 날에는 연구지원팀과 미리 협의해 후드별 사용 시간표를 정하고 그 내용을 점검표 비고란에 적어 다음 사용자도 알 수 있게 한다.
+
+## 사용 후 정리
+
+1. 사용한 시약과 폐액 용기의 뚜껑을 닫아 지정 보관장으로 옮긴다.
+2. 작업대를 물티슈나 지정 세척제로 닦는다.
+3. 새시를 끝까지 내린다.
+4. 다음 사용자가 30분 안에 없으면 조명을 끄고 배기 팬은 그대로 둔다.
+
+배기 팬은 야간에도 끄지 않는다. 팬을 끄면 후드 안에 남은 증기가 실험실로 퍼질 수 있고, 다시 켰을 때 면속도가 안정되기까지 3분 정도가 걸린다.
+
+# 월간 풍속 측정
+
+## 측정 준비
+
+측정은 연구지원팀 담당자가 매월 첫째 주 화요일 오전에 한다. 측정 전날 실험실 게시판과 메일로 측정 시간을 알리고, 측정 시간에는 해당 흄후드를 쓰지 않도록 사용 예약을 막는다. 열선 풍속계는 연 1회 교정을 받은 것을 쓰고, 교정 만료일을 측정 기록에 함께 적는다.
+
+## 측정 방법
+
+1. 새시를 작업 높이 40cm에 맞추고 후드 안의 물건을 모두 꺼낸다.
+2. 개구부를 가로 3칸, 세로 2칸으로 나눠 6개 지점을 정한다.
+3. 각 지점 중앙에서 풍속계 탐침을 새시 면과 같은 높이에 두고 10초간 평균값을 읽는다.
+4. 6개 값의 평균을 면속도로 기록하고, 가장 낮은 값과 가장 높은 값도 함께 적는다.
+5. 표시창 값과 측정 평균의 차이가 0.05m/s를 넘으면 표시창 보정을 요청한다.
+
+표 2. 2026년 3분기 면속도 측정 결과 (예시)
+
+| 설비 | 7월 (m/s) | 8월 (m/s) | 9월 (m/s) | 판정 |
+| --- | ---: | ---: | ---: | --- |
+| FH-301-1 | 0.52 | 0.50 | 0.51 | 적합 |
+| FH-301-2 | 0.48 | 0.47 | 0.45 | 적합 |
+| FH-301-3 | 0.55 | 0.54 | 0.55 | 적합 |
+| FH-302-1 | 0.43 | 0.39 | 0.47 | 8월 부적합 |
+| FH-302-2 | 0.50 | 0.51 | 0.50 | 적합 |
+| FH-302-3 | 0.58 | 0.57 | 0.58 | 적합 |
+
+자료: 연구지원팀 월간 측정 기록
+
+FH-302-1의 8월 값은 기준 하한 0.4m/s 아래였다. 배기 덕트 댐퍼가 반쯤 닫혀 있던 것이 원인이었고, 댐퍼를 연 뒤 재측정에서 0.47m/s로 돌아왔다.
+
+# 이상 시 조치
+
+## 판정 기준과 조치
+
+표 3. 이상 유형별 조치 (예시)
+
+| 이상 유형 | 1차 조치 | 연락처 | 재사용 조건 |
+| --- | --- | --- | --- |
+| 면속도 0.4m/s 미만 | 사용 중지, 표지 부착 | 연구지원팀 3150 | 재측정 적합 |
+| 면속도 0.6m/s 초과 | 사용 가능, 신고 | 연구지원팀 3150 | 다음 월간 측정 |
+| 배기 경보 | 작업 중지, 새시 닫기 | 연구지원팀 3150 | 원인 제거, 재측정 |
+| 새시 걸림 | 사용 중지 | 시설팀 3200 | 수리 완료 |
+| 시약 유출 | 유출 키트 사용 | 안전관리실 3119 | 정화 확인 |
+
+면속도가 기준보다 높은 경우에는 바로 위험하지는 않지만, 새시 가장자리에서 기류가 소용돌이쳐 오히려 증기가 밖으로 새는 일이 생긴다. 신고를 받으면 연구지원팀이 다음 월간 측정 전에 댐퍼를 조정한다.
+
+## 수리 후 재사용
+
+수리나 조정이 끝나면 연구지원팀 담당자가 3장의 측정 방법으로 면속도를 다시 잰다. 결과가 적합이면 사용 금지 표지를 떼고 수리 이력 대장과 안전 관리 시스템에 수리 내용, 측정값, 재사용 일시를 적는다. 같은 흄후드에서 3개월 안에 같은 이상이 두 번 생기면 외부 검사 기관에 정밀 검사를 의뢰한다.