diff --git a/.gitignore b/.gitignore
index 3eb848f..ac04211 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ packages/npm-core-rs/site-dist/
packages/npm-core-rs/*.tgz
packages/npm-core-rs/tmp/
target/
+packages/core-rs/src/generators/hwpx/reference/*-sample.hwpx
diff --git a/README.md b/README.md
index 9acc732..7e41f90 100644
--- a/README.md
+++ b/README.md
@@ -1,16 +1,66 @@
-# docxly core-rs
+
+
docxly core-rs
+
Embeddable Rust/WASM document generation for DOCX and HWPX.
+
Where Pandoc is a general-purpose converter, docxly is designed to live inside Node services, browser workflows, and product surfaces as a library.
+
+
+
+
+
+
+
-`docxly/core-rs` is a Rust-first mono repo for a Markdown-based DOCX/HWPX generation library, plus an npm-facing WASM wrapper package.
+Language: [English](/Users/limchaesung/Github/docxly/core-rs/README.md) · [한국어](/Users/limchaesung/Github/docxly/core-rs/docs/ko/README.md) · [Docs](/Users/limchaesung/Github/docxly/core-rs/docs/README.md)
-The project is being developed with a TDD-first workflow. The current milestone implements the DOCX rich slice and is bringing up HWPX compatibility from a minimal package baseline.
+`docxly/core-rs` currently measures at an 80 ms cold start and a 2 ms steady median, versus 284 ms cold and 210 ms steady for Pandoc on the summary DOCX benchmark corpus, a 105x steady-state advantage while also exposing browser-local generation and HWPX support from the same Rust core.
-## Live Demo
+The project is developed with a TDD-first workflow. The current milestone implements the DOCX rich slice and an approved HWPX baseline backed by manually validated golden fixtures.
-Try the browser demo on GitHub Pages:
+## Install
-- https://docxly.github.io/core-rs/
+The fastest way to start using docxly today is the npm package:
-The live page uses the published WASM wrapper and downloads a real `.docx` file directly in the browser.
+```bash
+npm install @docxly/core-rs
+```
+
+The Rust crate is the source of truth in this repository and can be consumed from the workspace or as a path dependency:
+
+```toml
+[dependencies]
+core-rs = { path = "packages/core-rs" }
+```
+
+## Quick Start
+
+### Node
+
+```js
+import { writeFile } from "node:fs/promises";
+import { generateDocx } from "@docxly/core-rs";
+
+const bytes = await generateDocx("# Hello\n\nThis is **docxly**.");
+await writeFile("output.docx", bytes);
+```
+
+### Rust
+
+```rust
+use std::fs;
+
+use core_rs::{DocxOptions, generate_docx};
+
+let docx = generate_docx("# Hello\n\nThis is **docxly**.", DocxOptions::default())?;
+fs::write("output.docx", docx)?;
+```
+
+## Why docxly
+
+- Build document generation directly into a product instead of shelling out to a converter.
+- On the current summary corpus, generate complex DOCX output in `2 ms` steady median versus Pandoc's `210 ms`, with `80 ms` versus `284 ms` cold start.
+- Use the same Rust core across Node, browser, and HWPX workflows.
+- Start with DOCX today and expand into HWPX from the same repository.
+- Ship deterministic outputs backed by fixture-driven tests and normalized archive checks.
## Live Demo
@@ -20,6 +70,39 @@ Try the browser demo on GitHub Pages:
The live page uses the published WASM wrapper and downloads a real `.docx` file directly in the browser.
+
+
+## Why docxly instead of Pandoc?
+
+Pandoc is a general-purpose converter; docxly is an embeddable generation engine.
+
+Use docxly when document generation must live inside a Node service, browser workflow, or product surface. Use Pandoc when you need broad format conversion and a CLI-first publishing workflow.
+
+| Corpus | docxly cold | Pandoc cold | docxly steady | Pandoc steady | Speed ratio |
+| --- | --- | --- | --- | --- | --- |
+| Small | 66 ms | 539 ms | 1 ms | 249 ms | 369.84x |
+| Medium | 80 ms | 284 ms | 2 ms | 126 ms | 64.85x |
+| Large | 88 ms | 219 ms | 4 ms | 210 ms | 57.60x |
+| Summary | 80 ms | 284 ms | 2 ms | 210 ms | 105.00x |
+
+| Capability | docxly | Pandoc |
+| --- | --- | --- |
+| Embeddable in app | Yes, library-first for Node and browser bundlers | CLI-first with process invocation |
+| Browser-local generation | First-party browser package and WASM path | Possible through pandoc.wasm, not the primary npm workflow |
+| npm distribution | Published package | Not a first-party npm package |
+| HWPX generation | Supported in the Rust core | Not supported |
+| Broad format conversion | Focused on DOCX and HWPX generation | Wide multi-format conversion |
+| DOCX reference-template workflow | Not a reference.docx workflow | Supported via reference.docx |
+
+Measured on darwin 25.2.0 / arm64 at 2026-03-10T14:29:12.752Z with Node v23.7.0 and Pandoc 3.9.
+
+- This benchmark measures DOCX generation only and does not compare HWPX.
+- The numbers above come from an offline Node environment and are not browser runtime timings.
+- Cold timings include WASM initialization for docxly and process startup for Pandoc.
+- Steady timings are medians from 15 runs after one warm-up per corpus.
+
+
+
## Workspace Layout
```text
@@ -43,9 +126,9 @@ The live page uses the published WASM wrapper and downloads a real `.docx` file
- Implemented: Markdown parser, internal shared intermediate model, deterministic DOCX packaging
- Implemented: fixture-driven integration tests with normalized hash comparison
- Implemented: strict/fallback handling for unsupported HTML, non-data images, and deep nested lists
-- In progress: HWPX compatibility bring-up from a minimal Hancom-compatible package baseline
-- Current HWPX CI gates only manually approved fixtures; `core-paragraph`, `core-heading`, `core-inline-style`, `core-link-text`, `core-mixed`, `style-typography`, `style-centered-layout`, and `style-brand-color` are the current approved baselines
-- Stale compatibility snapshots are quarantined and used only for reverse-engineering
+- Implemented: approved HWPX baseline backed by manually validated fixtures
+- Current HWPX CI gates use these approved fixtures: `core-paragraph`, `blockquote-basic`, `code-block-basic`, `core-heading`, `core-inline-style`, `core-link-text`, `core-mixed`, `list-basic`, `list-nested-depth-2`, `style-typography`, `style-centered-layout`, and `style-brand-color`
+- Provisional and quarantined HWPX artifacts are excluded from the release gate
- HWPX style options currently apply to body paragraphs and heading paragraphs; future block types such as lists and tables may add more paragraph categories
## Supported Markdown Today
@@ -104,7 +187,7 @@ Current options:
Notes:
- `generate_docx` returns a deterministic `.docx` archive as `Vec`
-- `generate_hwpx` currently targets a minimal compatibility baseline and is still being validated against Hancom
+- `generate_hwpx` targets the approved HWPX baseline reproduced by the committed golden fixtures
- `HwpxStyleOptions` currently supports document-level body/heading font, body/heading size, text/link/heading color, and paragraph alignment overrides
- Custom HWPX fonts are best-effort only; the current HWPX path records font family names but does not embed font binaries
- internal modules such as parser/model/generator helpers are not part of the public contract
@@ -113,7 +196,8 @@ Notes:
The current HWPX path is narrower than the DOCX rich slice.
-- approved baseline: `core-paragraph`, `core-heading`, `core-inline-style`, `core-link-text`, `core-mixed`
+- approved baseline: `core-paragraph`, `blockquote-basic`, `code-block-basic`, `core-heading`, `core-inline-style`, `core-link-text`, `core-mixed`
+- approved list baseline: `list-basic`, `list-nested-depth-2`
- approved style baseline: `style-typography`, `style-centered-layout`, `style-brand-color`
- supported content today:
- paragraphs
@@ -121,11 +205,8 @@ The current HWPX path is narrower than the DOCX rich slice.
- visible-text emphasis/strong/code/link rendering inside the approved compatibility contract
- document-level HWPX style overrides
- not yet part of the approved HWPX baseline:
- - lists
- tables
- images
- - blockquotes
- - fenced code blocks
Example HWPX generation:
@@ -273,10 +354,11 @@ hash.txt
## HWPX Reference Material
-- `/Users/limchaesung/Github/docxly/core-rs/packages/core-rs/src/generators/hwpx/docs/README.md`
-- `/Users/limchaesung/Github/docxly/core-rs/packages/core-rs/src/generators/hwpx/docs/schema-md/index.md`
+- `packages/core-rs/src/generators/hwpx/docs/README.md`
+- `packages/core-rs/src/generators/hwpx/docs/schema-md/index.md`
+- `packages/core-rs/src/generators/hwpx/reference/paragraph-only`
-These files are the repository-level reference corpus for HWPX work. They combine curated implementation notes with Markdown conversions of official Hancom PDF references, KS X 6101 source metadata, and a synthetic compatibility corpus.
+These files are the repository-level reference corpus for HWPX work. They combine curated implementation notes, Markdown conversions of Hancom reference material, and the local approved/reference fixtures used to keep the package contract stable.
## Development Notes
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..c0afbc8
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,15 @@
+# Docs
+
+`docxly` documentation is organized by entrypoint, similar to a product docs hub.
+
+## Languages
+
+- [English (repository README)](/Users/limchaesung/Github/docxly/core-rs/README.md)
+- [한국어](/Users/limchaesung/Github/docxly/core-rs/docs/ko/README.md)
+
+## Sections
+
+- [Getting Started](/Users/limchaesung/Github/docxly/core-rs/docs/ko/getting-started.md)
+- [Runtime Guide](/Users/limchaesung/Github/docxly/core-rs/docs/ko/runtime.md)
+- [Benchmark and Positioning](/Users/limchaesung/Github/docxly/core-rs/docs/ko/benchmark.md)
+- [Design System](/Users/limchaesung/Github/docxly/core-rs/docs/ko/design-system.md)
diff --git a/docs/ko/README.md b/docs/ko/README.md
new file mode 100644
index 0000000..466d070
--- /dev/null
+++ b/docs/ko/README.md
@@ -0,0 +1,31 @@
+# docxly 문서
+
+`docxly`는 DOCX와 HWPX 생성을 애플리케이션 내부에 직접 내장하기 위한 Rust/WASM 문서 생성 엔진입니다.
+
+Pandoc이 범용 문서 변환기라면, `docxly`는 Node 서비스, 브라우저 워크플로, 제품 UI 안에 직접 들어가는 라이브러리 경로에 초점을 맞춥니다.
+
+## 시작하기
+
+- [빠른 시작](/Users/limchaesung/Github/docxly/core-rs/docs/ko/getting-started.md)
+- [런타임 가이드](/Users/limchaesung/Github/docxly/core-rs/docs/ko/runtime.md)
+- [성능 비교와 포지셔닝](/Users/limchaesung/Github/docxly/core-rs/docs/ko/benchmark.md)
+- [디자인 시스템](/Users/limchaesung/Github/docxly/core-rs/docs/ko/design-system.md)
+
+## 핵심 수치
+
+- 현재 summary benchmark 기준 `docxly`는 `80 ms cold / 2 ms steady`
+- 같은 코퍼스에서 Pandoc은 `284 ms cold / 210 ms steady`
+- steady 기준으로 `105x` 빠른 수치가 측정됨
+
+## 언제 docxly를 선택해야 하나
+
+- 문서 생성을 별도 CLI 프로세스가 아니라 애플리케이션 내부 라이브러리로 붙이고 싶을 때
+- Node와 브라우저에서 같은 Rust 코어를 재사용하고 싶을 때
+- DOCX뿐 아니라 HWPX까지 같은 저장소와 API 흐름으로 확장하고 싶을 때
+- 테스트 가능한 결정적 출력과 fixture 기반 검증이 필요할 때
+
+## 바로 가기
+
+- [루트 README](/Users/limchaesung/Github/docxly/core-rs/README.md)
+- [npm package README](/Users/limchaesung/Github/docxly/core-rs/packages/npm-core-rs/README.md)
+- [라이브 데모](https://docxly.github.io/core-rs/)
diff --git a/docs/ko/benchmark.md b/docs/ko/benchmark.md
new file mode 100644
index 0000000..83afccf
--- /dev/null
+++ b/docs/ko/benchmark.md
@@ -0,0 +1,42 @@
+# 성능 비교와 포지셔닝
+
+## 요약
+
+`docxly`는 Pandoc의 대체 CLI가 아니라, 앱 내부에 문서 생성을 임베드하기 위한 라이브러리 경로를 제공합니다.
+
+- `docxly`: embeddable generation engine
+- `Pandoc`: general-purpose converter
+
+## 현재 summary benchmark
+
+- `docxly`: `80 ms cold / 2 ms steady`
+- `Pandoc`: `284 ms cold / 210 ms steady`
+- steady median 기준 `105x`
+
+측정 조건:
+
+- 환경: `darwin 25.2.0 / arm64`
+- Node: `v23.7.0`
+- Pandoc: `3.9`
+- 기준: complex DOCX benchmark corpus
+
+## 해석
+
+- cold start는 초기화 비용을 포함합니다.
+ - `docxly`: WASM initialization 포함
+ - `Pandoc`: process startup 포함
+- steady median은 warm-up 이후 반복 생성 비용을 의미합니다.
+- 이 수치는 브라우저 실측이 아니라 offline Node benchmark입니다.
+
+## 언제 Pandoc이 더 적합한가
+
+- 폭넓은 문서 포맷 변환이 필요할 때
+- CLI 중심 출판 파이프라인이 있을 때
+- `reference.docx` 기반 커스터마이징 흐름이 필요할 때
+
+## 언제 docxly가 더 적합한가
+
+- 앱 내부에 직접 문서 생성 기능을 붙여야 할 때
+- Node와 브라우저에서 같은 코어를 재사용해야 할 때
+- HWPX까지 같은 제품 흐름 안에서 다뤄야 할 때
+- 별도 프로세스 의존성 없이 라이브러리 형태로 배포하고 싶을 때
diff --git a/docs/ko/design-system.md b/docs/ko/design-system.md
new file mode 100644
index 0000000..685bff7
--- /dev/null
+++ b/docs/ko/design-system.md
@@ -0,0 +1,292 @@
+# docxly 데모 디자인 시스템
+
+`docxly` 데모 UI를 blue-first 제품 스타일로 재구성하기 위한 구현 기준 문서다. 이 문서는 데모 페이지를 바로 다시 설계할 수 있도록 토큰, 위계, 컴포넌트 규칙, 로고 슬롯 규칙을 결정 완료 상태로 정의한다.
+
+## Overview
+
+### 제품 성격
+
+- embeddable document engine
+- Node, browser, Rust 코어를 공유하는 문서 생성 제품
+- CLI 도구가 아니라 앱 내부에 들어가는 라이브러리 경험이 핵심
+
+### 대상 사용자
+
+- 앱과 서비스에 문서 생성을 직접 내장하려는 개발자
+- 브라우저와 Node에서 같은 코어를 쓰고 싶은 팀
+- DOCX뿐 아니라 HWPX까지 같은 제품 흐름으로 확장하려는 팀
+
+### 디자인 목표
+
+- product-like clarity
+- generator-first usability
+- blue-first technical brand identity
+
+## Brand Foundation
+
+### 핵심 브랜드 문장
+
+- `docxly is an embeddable document generation engine.`
+- `docxly brings DOCX and HWPX generation into the product surface, not a separate conversion step.`
+
+### 로고 슬롯 규칙
+
+- 위치: hero 내부 맨 위 좌측
+- 형태: `logo mark + wordmark` 또는 `docxly` 텍스트 lockup
+- 최소 높이: desktop 28px, mobile 24px
+- clear space: 로고 높이의 0.5배
+- 기본 배경: 밝은 surface 위 단색 사용
+- dark surface 위 사용 시 단색 역상 버전만 허용
+
+### 로고 없는 상태의 fallback
+
+- 실제 로고 자산이 없으면 `docxly` 워드마크 텍스트를 사용한다.
+- fallback 서체는 sans-serif display 계열로 고정한다.
+- fallback은 headline과 분리된 독립 요소여야 하며, hero heading 안에 합치지 않는다.
+
+## Color System
+
+### Core Tokens
+
+| Token | Value | Role |
+| --- | --- | --- |
+| `--color-primary-050` | `#eff6ff` | page tint, subtle highlight |
+| `--color-primary-100` | `#dbeafe` | soft border, soft chip |
+| `--color-primary-500` | `#2563eb` | selected state, active fill |
+| `--color-primary-600` | `#1d4ed8` | primary CTA |
+| `--color-primary-700` | `#1e40af` | hover / pressed CTA |
+| `--color-neutral-950` | `#0f172a` | headline, strong surface |
+| `--color-neutral-700` | `#334155` | body text |
+| `--color-neutral-500` | `#64748b` | muted text |
+| `--color-neutral-200` | `#e2e8f0` | border, divider |
+| `--color-surface` | `#ffffff` | base panel surface |
+| `--color-surface-muted` | `#f8fafc` | muted background |
+| `--color-success` | `#15803d` | success status |
+| `--color-error` | `#b91c1c` | error status |
+
+### Usage Rules
+
+- primary CTA는 `primary-600`
+- primary CTA hover는 `primary-700`
+- selected tab, selected chip, active proof highlight는 `primary-500`
+- soft tint 배경은 `primary-050`
+- border 기본값은 `neutral-200`
+- body text는 `neutral-700`
+- muted helper text는 `neutral-500`
+- dark comparison/proof strip 표면은 `neutral-950` 기반으로 사용
+
+### Explicit Constraints
+
+- 기존 warm/orange accent는 primary palette에서 제거한다.
+- warning/emphasis 보조색도 이번 문서 기준에서는 정의하지 않는다.
+- text on primary는 white only다.
+- 본문 텍스트 대비는 WCAG AA 이상을 유지한다.
+
+## Typography
+
+### Type Roles
+
+- display: hero headline 전용
+- heading: section title, card title
+- body: paragraph, helper, note
+- mono: install command, textarea, generated status
+- label: tab, eyebrow, compact metadata
+
+### Type Scale
+
+| Token | Desktop | Mobile | Usage |
+| --- | --- | --- | --- |
+| `display-1` | `56/1.0` | `40/1.02` | hero headline |
+| `heading-2` | `32/1.05` | `26/1.08` | section heading |
+| `body-1` | `16/1.6` | `16/1.6` | default paragraph |
+| `body-2` | `14/1.55` | `14/1.55` | helper, note |
+| `label` | `12/1.2` | `12/1.2` | uppercase label |
+
+### Type Rules
+
+- hero body는 최대 2문장
+- comparison meta는 1줄만 허용
+- install helper는 1문장만 허용
+- note/debug 문구는 body-2로만 표현
+
+## Layout
+
+### Page Frame
+
+- page width: max 1120px
+- panel radius: 20px
+- hero top padding: 40px desktop, 24px mobile
+- section gap: 24px
+
+### Spacing Scale
+
+- `8`
+- `12`
+- `16`
+- `24`
+- `32`
+- `48`
+
+### Hero Layout
+
+- desktop: `content column + install card` 2열
+- content column 내부 순서:
+ - logo
+ - one-line value proposition
+ - short supporting sentence
+ - external links max 2개
+ - compact proof strip
+- comparison strip은 content column 내부에만 배치
+- install card는 독립 보조 카드 1개만 허용
+
+### Mobile Layout
+
+- 모바일 1열 순서:
+ - logo/value proposition
+ - install card
+ - compact proof strip
+ - generator panel
+- `390x844` 기준 first viewport 안에 `logo + headline + install action`이 보여야 한다.
+- first viewport 안에 proof strip 전체가 보일 필요는 없지만, strip 시작부는 보여야 한다.
+
+## Component Rules
+
+### Hero
+
+- 최대 2개 text paragraph
+- 외부 링크 최대 2개
+- hero 안에 독립 강조 카드 2개 초과 금지
+- value proposition은 1문장으로 끝낸다
+
+### Install Card
+
+- command
+- copy button
+- 1-line helper
+- 1-line proof copy using the benchmark summary headline number
+
+canonical install proof:
+
+- `Install the embeddable DOCX engine that measured 105x faster than Pandoc on the summary benchmark.`
+
+금지:
+
+- 여러 installation option 동시 노출
+- verbose explanation
+- secondary CTA 추가
+
+### Proof Strip
+
+- KPI 3개 고정
+ - docxly steady
+ - pandoc steady
+ - speed ratio
+- 1줄 해석 허용
+- badge 1개 허용
+- long metadata는 1줄만 허용
+
+금지:
+
+- comparison table
+- dual comparison cards
+- 긴 explanatory paragraph
+- feature matrix
+
+### Generator Panel
+
+- 데모의 가장 높은 interaction priority 유지
+- 유지 대상:
+ - format tabs
+ - markdown textarea
+ - title input
+ - author input
+ - strict mode toggle
+ - generate button
+ - status
+ - note
+
+### Tabs
+
+- active = filled blue
+- inactive = neutral ghost
+- uppercase label
+- tab label은 한 단어 또는 짧은 약어만 허용
+
+### Buttons
+
+- variants:
+ - primary
+ - secondary
+ - ghost
+- primary는 blue fill
+- secondary는 neutral tint
+- ghost는 borderless text action
+
+## Content Hierarchy
+
+### First Screen Order
+
+1. logo
+2. one-line value proposition
+3. short supporting sentence
+4. primary install action
+5. compact proof strip
+
+install proof line은 comparison strip보다 먼저 읽히는 핵심 설치 유도 문장으로 배치한다.
+
+### Comparison Handling
+
+- comparison은 landing에서 제거하지 않는다.
+- 하지만 역할은 `compact support proof`로만 제한한다.
+- `Choose docxly / Choose Pandoc` 장문 카피는 기본 landing에서 제거 대상이다.
+- feature matrix와 장문 포지셔닝 설명은 docs 또는 하단 secondary content로 이동한다.
+
+## Do / Don't
+
+### Do
+
+- hero에서 한 가지 핵심 행동만 강조한다.
+- proof는 숫자 중심으로 압축한다.
+- blue tokens만으로 CTA와 active state를 통일한다.
+- generator panel을 가장 중요한 작업 영역으로 유지한다.
+- 로고를 headline과 별도 계층으로 분리한다.
+
+### Don't
+
+- 상단에 독립 강조 카드 3개 이상 배치하지 않는다.
+- comparison table을 landing first screen에 노출하지 않는다.
+- warm/orange palette를 primary accent로 사용하지 않는다.
+- 긴 비교 카피를 generator보다 먼저 배치하지 않는다.
+- install card와 comparison strip을 같은 강도의 경쟁 블록으로 만들지 않는다.
+
+## Acceptance Criteria
+
+이 문서만 읽고 구현자는 추가 질문 없이 다음을 수행할 수 있어야 한다.
+
+- CSS custom property 정의
+- hero 구조 재배치
+- install card / compact proof strip / generator panel 위계 적용
+- 로고 자산 도입 전 fallback lockup 구현
+
+추가 완료 조건:
+
+- 모바일 `390x844` 기준 first screen에 `logo + headline + install action`이 모두 보여야 한다는 기준이 명시돼 있어야 한다.
+- comparison은 `support proof`로만 남고, 장문 설명과 표는 기본 landing에서 제거 대상으로 명시돼 있어야 한다.
+- primary accent가 blue token family로 통일된다고 명시돼 있어야 한다.
+
+## Migration Notes
+
+현재 데모 UI에서 제거 또는 축소해야 하는 요소:
+
+- warm/orange 중심 accent
+- landing 상단의 장문 comparison explanation
+- feature matrix table
+- dual comparison choice blocks
+- hero에서 경쟁하는 다중 강조 카드
+
+새 UI로 옮길 때 유지해야 하는 요소:
+
+- install command 복사 흐름
+- summary benchmark proof
+- HWPX/DOCX format switching
+- browser-local generation 메시지
diff --git a/docs/ko/getting-started.md b/docs/ko/getting-started.md
new file mode 100644
index 0000000..c9323de
--- /dev/null
+++ b/docs/ko/getting-started.md
@@ -0,0 +1,52 @@
+# 빠른 시작
+
+## 설치
+
+가장 빠른 시작 경로는 npm 패키지입니다.
+
+```bash
+npm install @docxly/core-rs
+```
+
+Rust crate는 이 저장소의 워크스페이스에서 바로 사용할 수 있습니다.
+
+```toml
+[dependencies]
+core-rs = { path = "packages/core-rs" }
+```
+
+## Node 예제
+
+```js
+import { writeFile } from "node:fs/promises";
+import { generateDocx } from "@docxly/core-rs";
+
+const bytes = await generateDocx("# Hello\n\nThis is **docxly**.");
+await writeFile("output.docx", bytes);
+```
+
+## Rust 예제
+
+```rust
+use std::fs;
+
+use core_rs::{DocxOptions, generate_docx};
+
+let docx = generate_docx("# Hello\n\nThis is **docxly**.", DocxOptions::default())?;
+fs::write("output.docx", docx)?;
+```
+
+## 로컬 데모 실행
+
+저장소 루트에서 아래 명령을 실행합니다.
+
+```bash
+npm install
+npm run demo
+```
+
+정적 Pages 산출물만 생성하려면:
+
+```bash
+npm run build:pages
+```
diff --git a/docs/ko/runtime.md b/docs/ko/runtime.md
new file mode 100644
index 0000000..256e37d
--- /dev/null
+++ b/docs/ko/runtime.md
@@ -0,0 +1,45 @@
+# 런타임 가이드
+
+## 지원 런타임
+
+- Node
+- 브라우저 번들러 환경
+- Rust workspace/path dependency
+
+## Node
+
+`@docxly/core-rs`는 비동기 API로 DOCX 생성을 제공합니다.
+
+- 기본 엔트리포인트: `generateDocx(markdown, options)`
+- 반환값: `Promise`
+- 주요 옵션: `title`, `author`, `strictMode`
+
+## 브라우저
+
+브라우저에서는 `.wasm` 자산을 처리할 수 있는 번들러가 필요합니다.
+
+- raw `
+