PDF를 휴대폰에서 돌아가는 도구로

# PocketBrief Spec v1.1

**A copy-paste protocol for turning PDFs into a single interactive HTML page that works on a phone.**

Works with any current commercial chat LLM (Claude, ChatGPT, Gemini, Copilot, …).
No installation, no coding, no account beyond the chat itself.

---

## How to use this (3 steps)

1. Open a new chat. **Paste this entire file.**
2. **Attach 1–2 PDFs** in the same message.
3. Send. You get back a page you can open on your phone.

Optionally edit the `SETTINGS` block below before sending. Everything else can stay as-is.

### What "you get it back" looks like, per app

The three big apps hand the result over in three different ways. None is wrong — but if you expect
the wrong one, you will think it failed.

| App | What you should expect | If you only get code, say this |
|---|---|---|
| **Claude** | An **artifact** — opens beside the chat, and downloads as a file. | "Put this in an artifact." |
| **ChatGPT** | A **canvas**, or a download link. Either is fine. | "Open this in canvas." |
| **Gemini** | A **Canvas preview** — then use the **share button** and open that link on your phone. **There is no file download, by design.** | "Make this a Canvas app and show me the preview." |

**Gemini users, read this line.** Gemini will not give you a `.html` file, and you do not need one.
Render it in Canvas, press **share**, open the link on your phone, and use *add to home screen* if you
want an icon for it. You never have to save a text file and rename it — if you find yourself doing
that, you are fighting the tool.

---

## SETTINGS — edit these five lines, or leave them

```
MODE:       brief              # brief = a reading tool | tool = a working instrument (§9)
LANGUAGES:  Korean + English   # one language, or two — two gives the page a language tab
DEFAULT:    Korean             # which one shows first, when two are requested
AUDIENCE:   general adult      # e.g. "practising clinicians", "medical students", "patients"
DEPTH:      standard           # quick | standard | thorough
TONE:       plain and direct   # e.g. "formal", "warm", "teaching"
EXTRAS:     none               # e.g. "add a quiz", "add a timeline"
```

> For one language only, write e.g. `LANGUAGES: Korean` and delete the `DEFAULT` line.
> For a source with rules, thresholds or formulas — a guideline, a protocol, a manual — try `MODE: tool`.

## Which model to run this on

This file is a long instruction set that asks for a long, exact output. That combination is where
models differ most.

| Tier | Behaviour on this spec | Use it when |
|---|---|---|
| **Fast mid-tier** (Sonnet-class, GPT mini-plus, Gemini Flash) | Usually the sweet spot. Follows the contract, finishes in one pass. | **Default. Start here.** |
| **Top tier** (Opus-class, GPT Pro-class, Gemini Pro) | Best judgement on messy or scanned PDFs — but slow, and the extra depth is mostly wasted on what is largely a mechanical transformation. | A hard source: bad scans, dense tables, conflicting text, or `MODE: tool` |
| **Small / free tier** | Often truncates, drops the second language, or reaches for a CDN. | Use `PocketBrief-Spec-LITE.md` instead, one language, `DEPTH: quick` |

If the output is slow or keeps getting cut off, degrade in this order — each step roughly halves the work:
`LANGUAGES` → one · `DEPTH: quick` · fewer sections · `MODE: brief` · switch to the LITE spec.

This is guidance from what the task demands, not a published benchmark. Models change; try two and keep
the one that finishes cleanly.

---

# INSTRUCTIONS TO THE MODEL

Everything below this line is addressed to you, the assistant. Follow it exactly.

## 1. Your role

You are a documentation engineer. You are given one or more PDFs. You will produce **one self-contained
HTML file** that lets a person on a phone understand and use the contents of those PDFs in a few minutes.

You are **not** writing a summary in prose. You are building a small, working application.

## 2. Output contract — this is strict

**Deliver something the reader can open, not source code to read.** A fenced code block is the last
resort, not the goal — on a phone it is useless. Use the best form your interface supports:

1. **A rendered document.** If you can create an artifact, a canvas document, or a live preview, do that.
   Best outcome: it opens on a phone with nothing to download.
2. **A downloadable file.** If you can write files, save it as `pocketbrief.html` and give the link.
3. **A fenced code block.** Only when you can do neither of the above.

**Do not treat "no file download" as failure.** Some interfaces — Gemini Canvas is the clearest case —
never produce a downloadable file, and that is fine. What they have instead is better for a phone:
a live preview, a **share link**, and an *add to home screen* option. If that is your environment,
render the page in the canvas and then tell the user, in one line, that they should use the share
button and open the link on their phone. Do not apologise for the absence of a download, do not
offer the raw code as a substitute, and never instruct the user to save your reply as a text file
and rename it to `.html` — that is a workaround for a problem you should not create.

Ranked by what the reader ends up with, a rendered-and-shareable page **beats** a downloaded file.
Reach for a download only when your interface has no way to display the page itself.

Then:

- The page is **one complete HTML document**, `<!DOCTYPE html>` … `</html>`. Never split it across two
  code blocks or two artifacts.
- Before it, write **at most three lines**: which delivery form you used, what the page contains, and
  anything you could not extract from the PDF.
- After it, write **nothing**.
- If your reply is cut off mid-file, and the user says "continue", resume at the exact character you
  stopped at. Do not restart, do not repeat, do not apologise.

## 3. Content rules — fidelity first

1. **Every fact in the page must come from the PDFs.** Invent nothing. Do not fill gaps with general
   knowledge, and do not add plausible-sounding detail that is not in the source.
2. **Numbers, doses, units, dates and names are copied verbatim.** Never round, never convert, never
   "clean up" a figure.
3. **Attribute everything.** Each section carries a small source line: `p. 12` for one PDF, or
   `[A] p. 12` / `[B] p. 4` when there are two. If you cannot determine a page, write `source: unclear`.
4. **Say what you could not read.** If a PDF is scanned, encrypted, image-only, or partly unreadable,
   state that in your three lines above the code block and put a visible banner in the page itself.
   Do not silently guess.
5. **Uncertainty is marked, not hidden.** If the source is ambiguous, render the text with the class
   `uncertain` and a short note. Never resolve an ambiguity by choosing for the reader.
6. **Privacy scrub.** If the PDFs contain personal or patient identifiers — names, ID or chart numbers,
   phone numbers, addresses, dates of birth, face photographs — **do not carry them into the HTML**.
   Replace with `[name]`, `[ID]`, `[date]`. Keep clinical content. State in the page that identifiers
   were removed. This rule outranks completeness.
7. **Do not give instructions the source does not give.** In particular, do not turn descriptive
   content into clinical, legal or financial advice. If the source is clinical, include a one-line
   note that the page is a reading aid, not a decision tool.

## 4. Required structure

The page must contain, in this order:

1. **Header** — title, one-sentence description, source file name(s) and page count. Sticky on scroll.
   If two languages were requested, the header carries the **language tab** (§6a).
2. **Key numbers** — 3 to 6 cards, each a single figure that matters, with its label and source page.
   Skip this section only if the source genuinely contains no figures.
3. **Sections** — the substance of the PDF, broken into collapsible sections. Every section has a
   one-line summary that is visible while collapsed, so the page is readable without any tapping.
   Aim for 5–12 sections. First section expanded, the rest collapsed.
4. **At least two interactive components** from §5.
5. **Footer** — generation note, the source file names, and the privacy statement.

## 5. Interactive components — choose at least two

Pick the ones the material actually justifies. A component with nothing to do is worse than no component.

- **Search / filter** — one input that live-filters sections and list items by substring, case-insensitive,
  and auto-expands sections containing a hit. Shows a "no matches" state.
- **Self-check quiz** — 3 to 8 multiple-choice questions drawn strictly from the source. Instant feedback,
  a one-line explanation per answer, and a score. Every explanation cites its page.
- **Checklist** — actionable items with tick boxes and a live progress count. Only if the source contains
  steps, criteria or requirements.
- **Glossary** — tap a term for its definition in a popover or inline panel. Only for terms the source defines.
- **Timeline** — chronological events, tappable for detail. Only if the source is chronological.
- **Comparison table** — sortable or toggleable columns. Only if the source compares things.
- **Calculator** — implement a formula that appears explicitly in the source, with the formula shown.
  Never invent or "improve" a formula. Show units. Never a dosing calculator unless the source states
  the full rule, and always with the source's own cautions attached.

Do not add a chart unless the source contains data with at least four points. If you do, draw it as
inline SVG that you generate yourself — no chart library.

## 6. Technical constraints — hard limits

**Self-contained**
- One file. All CSS in one `<style>`, all JS in one `<script>`.
- **Zero network requests.** No CDN, no Google Fonts, no external images, no `fetch`, no `import`.
  The page must work with the phone in airplane mode.
- No React, Vue, Tailwind, jQuery, Chart.js or any other library. Plain HTML, CSS and JavaScript.
- Images only as inline SVG or `data:` URIs, and only if genuinely needed. Prefer SVG you draw yourself.
- **No `localStorage`, `sessionStorage`, `indexedDB` or cookies.** Some chat preview panes block them and
  the page will crash. Keep all state in JavaScript variables.
- Target under 250 KB total.

**Mobile**
- `<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">`
- Must lay out correctly at **360 px wide**. No horizontal scrolling anywhere, ever.
- Body text **≥ 16px** — smaller triggers zoom-on-focus in iOS Safari.
- Every tappable target **≥ 44 × 44 px**, with visible spacing between adjacent targets.
- **No hover-dependent behaviour.** Anything reachable by hover must also work on tap.
- Respect the notch: `padding: env(safe-area-inset-*)` on fixed elements.
- Tables wider than the screen go in a `overflow-x:auto` wrapper with a visible scroll hint.
- Support `prefers-color-scheme: dark` and `light`. Both must be legible.

**Accessibility — assume some readers are over sixty**
- Include **A− / A+ text size buttons** in the header that scale the whole page. Start at 17px.
- Contrast ratio ≥ 4.5:1 for body text in both colour schemes.
- Semantic HTML: `<header> <main> <section> <button> <details>`. Use `<button>`, never a clickable `<div>`.
- `aria-expanded` on every collapsible control; visible `:focus-visible` outline.
- Respect `prefers-reduced-motion`: no animation when it is set.

**Language**
- Write the page in the language(s) given in `SETTINGS: LANGUAGES`, regardless of the PDF's own language.
- For Korean, Japanese or Chinese, add `word-break: keep-all; overflow-wrap: break-word` to body text so
  lines do not break mid-word.
- Keep technical terms and drug names in their original form, with a translation on first use.

## 6a. Two languages — the language tab

When `SETTINGS: LANGUAGES` names two languages, the page must contain **both, in full**, with a tab in the
header that switches between them instantly. Not a link to a second page — one file, one tap.

**Use exactly this pattern.** It is the one that survives being written by a language model.

```html
<body class="lang-ko">        <!-- SETTINGS: DEFAULT decides ko or en here -->
```
```css
.lang-ko [data-l="en"]{display:none}
.lang-en [data-l="ko"]{display:none}
```
```html
<!-- inline -->
<h2><span data-l="ko">항생제 경과</span><span data-l="en">Antibiotic course</span></h2>
<!-- block -->
<div data-l="ko"><p>…</p><ul>…</ul></div>
<div data-l="en"><p>…</p><ul>…</ul></div>
```
```html
<div class="langtab" role="group" aria-label="language">
  <button type="button" data-set="ko" aria-pressed="true">한국어</button>
  <button type="button" data-set="en" aria-pressed="false">EN</button>
</div>
```
```js
document.querySelectorAll('.langtab button').forEach(function(b){
  b.onclick = function(){
    document.body.className = 'lang-' + b.dataset.set;
    document.documentElement.lang = b.dataset.set;
    document.querySelectorAll('.langtab button').forEach(function(o){
      o.setAttribute('aria-pressed', String(o === b));
    });
  };
});
```

Rules that go with it:

- **Both versions carry the same facts.** The second language is a translation of the content, not a
  shorter or livelier variant. Numbers, page references and source lines are identical on both sides.
- **Never nest** a `data-l` element inside another `data-l` element.
- **Everything switches** — headings, summaries, body, quiz questions, quiz answers, quiz explanations,
  button labels, checklist items, the footer, the `<title>`. A half-translated page is a bug.
- Proper nouns, drug names, gene names, abbreviations and the source file name stay as they are on both
  sides. Do not translate `HbA1c`, `MRSA`, `PTA`, `HELIOS`.
- The two tab buttons are ≥ 44 px tall, and the active one is visibly distinct — not colour alone; use
  weight or a filled background too.
- Anything JavaScript generates (quiz items, filter messages, counters, empty states) must also exist in
  both languages. Keep the strings in one object, e.g. `var T = {ko:{…}, en:{…}}`, and read the current
  language from `document.body.className`.
- Search filters only what is currently visible: match against the active language's text.

**Length warning.** Two languages roughly doubles the file. If you are at risk of running out of room,
do not silently drop the second language and do not shorten one side — instead cover fewer sections,
keep both languages complete for the sections you do cover, and say in your three lines above the code
block which sections you left out.

## 7. Anti-patterns — do not do these

- ✗ Loading anything from a URL
- ✗ Lorem ipsum, `TODO`, placeholder rows, or "example data" mixed in with real content
- ✗ A summary so compressed that the numbers are gone
- ✗ A wall of text with a single "expand all" — that is a PDF with extra steps
- ✗ Interactivity that does nothing (a search box over three items, a quiz with obvious answers)
- ✗ Font sizes below 16px for body text, or grey-on-grey
- ✗ Silently dropping content you found hard to parse
- ✗ A language tab where one side is thinner than the other, or where the quiz stays in one language
- ✗ Telling the user to copy your code into a text editor and rename it to `.html`. If you cannot
  produce a file, render it and point at the share button instead (§2)
- ✗ Apologising for not offering a download when your interface has a preview and a share link — that
  path is better, not worse

## 8. Self-check before you answer

Verify each of these. If any fails, fix it before replying — do not mention the checklist in your answer.

```
[ ] Delivered as a rendered document or a file where the interface allows it — code block only as a fallback
[ ] One complete document, <!DOCTYPE html> … </html>, not split in two
[ ] Zero external requests — search your own output for "http", "//cdn", "@import", "fetch("
[ ] No localStorage / sessionStorage / cookies
[ ] Every number in the page appears in the PDF, unchanged
[ ] Every section has a source page reference
[ ] No personal identifiers survived
[ ] Renders at 360px with no horizontal scroll
[ ] Body text ≥ 16px, tap targets ≥ 44px, A−/A+ present
[ ] Dark and light both legible
[ ] At least two interactive components, each with something real to do
[ ] Collapsed page is still readable — every section shows its one-line summary
[ ] Anything unreadable in the PDF is declared, in the reply and in the page
[ ] If two languages: tab present, both sides complete, no data-l nested inside data-l,
    JS-generated strings translated, same numbers and page refs on both sides
```

## 9. `MODE: tool` — building a working instrument

In `brief` mode you produce a reading tool. In `tool` mode you find the parts of the source that can be
**operated** and turn them into something the reader drives.

Look for these, in this order of preference:

| What is in the source | What you build |
|---|---|
| Thresholds and cut-offs | A **classifier** — the reader enters values, the page states which band the source puts them in |
| Branching rules ("if X, then Y") | A **decision path** — answer a few questions, arrive at the applicable recommendation |
| Eligibility criteria | A **checklist that decides** — tick what applies, get the source's conclusion |
| An explicit formula | A **calculator** — with the formula and its units printed on screen |
| A large table | A **filterable table** — filter and sort, nothing computed |
| Staged or timed protocols | A **stepper** — one step at a time, with the source's timings |

### The rules that make this safe

1. **You implement, you do not infer.** Every threshold, branch and formula must be written in the source.
   If a branch is missing, the page says "출처에 없음 / not in the source" and stops there. Never complete
   a rule with your own knowledge, and never smooth over a gap to make the flow feel finished.
2. **Show the source text with every result.** A result is the verbatim sentence from the document plus
   its page reference — not your paraphrase of it. The reader must be able to check it without leaving
   the page.
3. **Verbatim stays in its original language.** Even when two languages are requested, quoted rules,
   recommendations and criteria are **not translated** — a translation is no longer verbatim. Translate the
   interface around them. If a translation of a quote genuinely helps, mark it clearly as unofficial and
   keep the original next to it.
4. **State, do not direct.** The page reports what the source says applies. It does not tell the reader
   what to do. Write "지침은 …라고 권고합니다 (p. N)", not "…하십시오".
5. **Carry the cautions.** If the source attaches conditions, exceptions, contraindications or an evidence
   grade to a rule, they travel with it. Never show a conclusion stripped of its qualifiers.
6. **Internal contradictions are surfaced, not resolved.** If two parts of the document disagree, show
   both with both page numbers and say they differ. Do not pick one.
7. **No dosing calculator** unless the source states the complete rule including limits, and the source's
   own warnings are displayed with the result.

### The banner — required, and always visible

Every `MODE: tool` page carries a warning that **cannot be dismissed and does not scroll away**. Build it
in two parts — a second sticky element under a sticky header gets hidden behind it on a phone, so do not
try that:

- **A one-line strip inside the sticky header itself**, in a caution colour. It is part of the header, so
  it is on screen at every scroll position. Keep it to one line: *"⚠ 불완전할 수 있습니다 — 판단 전 원문 확인 필수"*.
- **The full statement immediately below the header**, static, not sticky.

Repeat a short version next to every computed result.

> **이 도구는 원문을 옮긴 것이며 불완전할 수 있습니다. 판단 전에 반드시 원문을 확인하십시오.**
> This tool is a transcription of the source and may be incomplete. Check the original before acting on it.

Alongside it, state plainly: the source file name and edition, the date the page was generated, and — in
one line — what the tool does **not** cover. A reader must never be able to mistake it for the document.

If the source is clinical, legal or financial, add that the page is a reference aid and that the
responsibility for any decision stays with the reader.

---

# FOR THE PERSON — after you get the file

**If you only got a wall of code.** Some apps just print the source. Say the line for your app:

| Your app | Say this |
|---|---|
| **Claude** | *"Put this in an artifact."* / "이걸 아티팩트로 만들어줘." |
| **ChatGPT** | *"Open this in canvas."* / "이걸 캔버스로 열어줘." |
| **Gemini** | *"Make this a Canvas app and show me the preview."* / "이걸 Canvas 앱으로 만들어서 미리보기 보여줘." |
| **Anything else** | *"Save this as a downloadable .html file."* / "다운로드할 수 있는 .html 파일로 저장해줘." |

**Reading it right away.** Once it renders, the preview pane is usually enough on a phone — tap through
it there.

**Keeping it — and this differs by app.**

- **Gemini** — press **share**, open that link on your phone, then *add to home screen* for an icon.
  **Do not go looking for a download; Gemini does not have one.** You never need to save the code as a
  text file and rename it to `.html`. If you are doing that, you have taken the wrong path.
- **Claude / ChatGPT** — ask for *"a downloadable .html file"*, then:
  - **Android** — download it, open Chrome, `⋮ → Downloads`, tap the file.
  - **iPhone** — download it to Files, tap it to preview. To open it properly, long-press → Share → Safari.
- **Either way** — putting the file in Google Drive or Dropbox and opening the link on the phone also
  works, and is the easiest thing to send to someone else.

**Changing it.** Reply in the same chat with one sentence. Some that work well:

| Say this | You get |
|---|---|
| "Too long. Cut it to what a busy reader needs in 3 minutes." | A tighter version |
| "Add a self-check quiz, 5 questions." | A quiz |
| "The text is too small for me." | Larger base size |
| "Section 3 is wrong — the PDF says X." | A correction |
| "Make it work offline on a plane." | Verified zero-network |
| "Add a second PDF" + attach it | A merged page with `[A]`/`[B]` sources |
| "Add an English version with a language tab." | Both languages, one tap apart |

**If the reply gets cut off.** Say exactly: *"continue from where you stopped, no repetition"*.

**One caution.** The model can misread a PDF, especially scanned ones and tables. Spot-check the numbers
against the original before you rely on the page for anything that matters, and before you share it.

---

## Is this file safe to hand around?

**This file cannot execute.** Markdown is plain text — no macros, no scripts. Opening it is as safe as
opening a `.txt`. The extension carries no meaning; rename it to `.txt` if that travels better. An AI
reads either one identically.

**The real question is what a spec file instructs.** A prompt file from an unknown source could tell the
model to embed a tracking pixel, or to send the attached PDF's contents to some address. No antivirus
catches that, because nothing malicious is in the file — the instruction *is* the payload. The defence is
that a spec is a few pages of readable English: **read it before you paste it.** Note that this one
forbids every outbound connection, which is exactly what exfiltration would require.

**Give recipients a way to check the output.** Anyone can open the generated `.html` in a text editor and
search it:

- `http` — there should be **none**
- `localStorage`, `fetch` — there should be **none**

If those are absent, the page can only draw what is already inside it.

Two practical notes: many organisations strip `.html` email attachments, so share a link instead; and some
browsers warn on downloaded `.html` regardless of content, because the format *can* carry scripts. Neither
is a sign that anything is wrong.

---

*PocketBrief Spec v1.0 — free to copy, adapt and share.*

# PocketBrief LITE

Paste this, attach 1 PDF, send. Use this short version on small or free-tier models — the full spec
(`PocketBrief-Spec-v1.md`) asks for more than they reliably finish.

```
LANGUAGE: Korean          # the language of the finished page
AUDIENCE: general adult
```

---

**Task.** Read the attached PDF and build **one self-contained HTML page** that lets someone on a phone
understand it in a few minutes.

**How to deliver it.** I need something I can open on a phone, not source code to read. Give me the
finished page in the **best form your interface supports**, in this order:

1. A **rendered document** — if you can create an artifact, a canvas document, or a live preview, do that.
   This is the best outcome: it opens on a phone with no download.
2. A **downloadable `.html` file** — if you can write files, save it as `pocketbrief.html` and give me the link.
3. A **fenced code block** — only if you can do neither of the above.

If your interface has a canvas or preview but **no file download** — this is normal, Gemini Canvas
works this way — that is not a failure. Render the page there and tell me in one line to use the
**share button** and open the link on my phone. Never tell me to save your reply as a text file and
rename it to `.html`.

Whichever you choose, the page must be one complete document from `<!DOCTYPE html>` to `</html>`.
Say in one line which form you used. If you run out of room, stop mid-file — I will say "continue" and
you resume at the exact character you stopped at, with no repetition.

**Content.**
- Every fact comes from the PDF. Invent nothing.
- Copy numbers, units and dates exactly. Never round.
- Put the page number next to each section, like `p. 12`.
- If part of the PDF is unreadable, say so in the page instead of guessing.
- Remove any personal identifiers — names, ID numbers, dates of birth. Replace with `[name]`, `[ID]`.

**The page must have.**
1. A title, and the source file name.
2. Three to five **number cards** — the figures that matter.
3. Five to ten **collapsible sections**. Each shows a one-line summary while collapsed, so the page reads
   without tapping anything. First one open, rest closed.
4. A **search box** that hides sections not matching what is typed, and opens the ones that match.
5. `A−` and `A+` buttons that change the text size of the whole page.

**Technical — these are hard rules.**
- One file. CSS in one `<style>`, JS in one `<script>`.
- **No links to anything on the internet.** No CDN, no web fonts, no `fetch`. It must work in airplane mode.
- No React, Tailwind, jQuery or any library. Plain HTML, CSS, JavaScript.
- **No `localStorage` or cookies** — they are blocked in chat preview panes and will break the page.
- `<meta name="viewport" content="width=device-width, initial-scale=1">`
- Works at 360px wide with **no horizontal scrolling**.
- Body text at least 16px. Buttons at least 44px tall.
- Support dark mode with `@media (prefers-color-scheme: dark)`.
- For Korean, Japanese or Chinese text add `word-break: keep-all` so lines do not break mid-word.

**Before you answer, check:** delivered as a rendered document or a file if possible ·
no `http` anywhere in your output · no `localStorage` · every number matches the PDF ·
readable at 360px · dark mode legible.

---

### If you only got code

Some apps just print the source. Reply with the line for your app:

- **Claude** — "이걸 아티팩트로 만들어줘." / *"Put this in an artifact."*
- **ChatGPT** — "이걸 캔버스로 열어줘." / *"Open this in canvas."*
- **Gemini** — "이걸 Canvas 앱으로 만들어서 미리보기 보여줘." / *"Make this a Canvas app and show me the preview."*
- **Anything else** — "다운로드할 수 있는 .html 파일로 저장해줘."

**Gemini gives you no file download, and does not need to.** Once it renders in Canvas, press
**share**, open that link on your phone, and use *add to home screen* if you want an icon.
Saving the code as a text file and renaming it is never necessary.

You are given a PDF. Build ONE self-contained HTML page that lets someone read it on a phone in minutes.

Deliver it as a rendered artifact/canvas, or a downloadable .html file. A code block only as a last resort. If your canvas cannot produce a file (Gemini Canvas), that is fine - render it there and tell me in one line to use the share button and open the link on my phone. Never tell me to save your reply as a text file and rename it to .html.

CONTENT: Use only facts from the PDF. Invent nothing. Copy every number exactly. Put "p.N" on each section. Say what you could not read. Remove personal identifiers. Write the page in Korean.

PAGE: title + source filename; 3-5 number cards of the figures that matter; 5-10 collapsible sections, each showing a one-line summary while closed, first one open; a search box that hides non-matching sections; A- / A+ text-size buttons.

TECHNICAL: one file, CSS in one <style>, JS in one <script>. NO internet - no CDN, no web fonts, no images, no fetch. No libraries. No localStorage. Include viewport meta. Must work at 360px wide with no horizontal scrolling. Body text >=16px, tap targets >=44px. Dark mode via prefers-color-scheme. For Korean use word-break:keep-all.