# Gemini 노트 작업 지침서

이 지침서는 Gemini가 Obsidian 보관소(Vault) 내에서 노트를 생성하고 관리할 때 따라야 할 표준 프로토콜을 정의합니다. 모든 작업은 파일 관리의 효율성과 검색 용이성을 극대화하는 방향으로 수행되어야 합니다.

## 1. YAML 프론트매터(Properties) 관리

모든 노트의 최상단에는 아래의 표준 YAML 속성을 포함해야 합니다.

```yaml
---
aliases: []
category: [상위 폴더명 또는 주제]
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
summary: "노트 내용의 한 줄 요약"
---
```

## 13. 사례 글의 환자 식별자 및 개인정보 규칙

Pros_on 게시글은 공개 웹 콘텐츠이므로 환자 식별정보를 저장하거나 추정할 수 있는 값을 frontmatter, 파일명, slug, 본문, 이미지명에 넣지 않는다.

### ID와 slug

- `id`는 게시글의 내부 불변 식별자이며 환자명, 환자번호, 생년월일, 차트번호를 포함하지 않는다.
- 새 글의 `id`는 `post_` 뒤에 게시글 단위의 무작위 또는 자동 생성 식별자를 사용한다. 예: `post_20260810_a7f3`.
- 이미 발행된 글의 `id`는 절대 변경하지 않는다.
- `slug`에도 환자명, 이니셜, 생년월일, 병원 접수번호, 주문번호를 사용하지 않는다.
- 사례 slug는 공개 주제 중심의 영문 kebab-case로 작성한다. 예: `custom-prosthesis-fitting-case`.
- 내부 환자 관리용 ID와 홈페이지 게시글 `id`는 서로 다른 체계로 유지한다.

### 사용 금지 정보

다음 정보는 공개 글에 직접 입력하지 않는다.

- 환자 실명, 이니셜, 이름 일부, 별칭
- 생년월일, 나이와 날짜를 결합한 식별 가능한 정보
- 전화번호, 주소, 이메일, 병원명, 차트번호, 주문번호
- XML 파일명, 원본 사진 파일명, 환자 폴더명 등 내부 경로 정보
- 얼굴, 문서, 처방전, 의뢰서, 명찰 등 식별 가능한 이미지
- 환자를 특정할 수 있는 희귀 질환·지역·직업·사고 일시의 조합

### 사례 글 작성 방식

- 환자는 `사례 대상자`, `사용자`, `한 사례의 사용자`처럼 익명 표현으로 작성한다.
- 환자별 연계 페이지, 환자 허브, 내부 관리 링크를 홈페이지에 만들지 않는다.
- 사례를 구분해야 할 때는 환자 정보가 아닌 주제·제작 목적·기능 중심의 공개 사례 ID를 사용한다. 예: `case_20260810_01`.
- 내부 문서와 공개 게시글을 연결해야 할 경우에도 공개 게시글에는 내부 링크와 환자 식별자를 넣지 않는다.
- 공개 동의가 확인되지 않은 사례는 `published: false`로 유지하고 발행하지 않는다.

### LLM 작성 및 발행 절차

LLM은 글을 작성하기 전에 다음을 확인한다.

1. 원자료에 환자 식별정보가 포함되어 있는지 확인한다.
2. 게시글에는 공개 가능한 내용만 남기고 식별정보를 제거한다.
3. `id`와 `slug`가 환자 정보와 무관한지 확인한다.
4. 제목·description·본문·이미지 파일명·alt 문구를 함께 검사한다.
5. `published: false` 상태로 초안을 저장한다.
6. 사람이 공개 동의와 개인정보 제거 상태를 검토한 뒤에만 `published: true`로 변경한다.

LLM은 정보가 부족하거나 공개 동의 여부가 불명확한 경우 추측으로 보완하지 말고, 해당 항목을 비워 두거나 사용자에게 확인을 요청한다.

- **aliases**: 문서의 다른 이름이나 약어를 리스트 형식으로 기재합니다.
- **category**: 문서의 성격을 나타내는 대분류를 입력합니다. (예: `수가 개선 자료`, `20. Project`, `50. Archive/독일_출장`)
- **created/updated**: 생성 및 수정 날짜를 `YYYY-MM-DD` 형식으로 기재합니다. (수정 시 updated 날짜 갱신 필수)
- **tags**: 아래 '2. 태그 시스템' 지침을 따릅니다. (주의: YAML 내에서는 `#` 기호를 제외하고 입력합니다.)
- **summary**: 검색 결과에서 미리보기로 활용될 수 있도록 내용을 간결하게 요약합니다.

## 2. 태그(Tags) 시스템 지침

태그는 검색의 정밀도를 높이기 위해 계층적 구조와 상태 정보를 포함합니다.

- **핵심 키워드**: `주제/세부주제` 형식 (예: `수가/독일`, `의지/소켓`)
- **문서 유형**: `유형/보고서`, `유형/메모`, `유형/회의록`
- **관리 태그**: 지식의 상태나 중요도를 표시합니다. (예: `상태/완료`, `중요`)
- **주의사항**: 
    - YAML 프론트매터의 `tags` 필드에는 `#`를 붙이지 않으며, 본문 내에서 인라인 태그로 사용할 때만 `#`를 붙입니다.
    - **태그명 내부에는 공백(띄어쓰기)을 허용하지 않습니다.** 단어 연결이 필요한 경우 반드시 언더바(`_`)를 사용해야 합니다. (예: `기초_안내`, `사용_방법`)
- **최소 3개 이상**의 의미 있는 태그를 생성하거나 유지합니다.

## 3. 연결성(Links) 및 네비게이션 표준

노트 간의 연결은 최상단 네비게이션과 본문 내 맥락 링크를 원칙으로 합니다.

- **최상단 네비게이션 (Breadcrumbs)**: YAML 프론트매터 바로 아래(본문 시작점)에 현재 노트의 상위 맥락이나 소속을 기재합니다.
    - 형식: `Up: [[상위노트명]]` 또는 `Context: [[프로젝트명]]`
- **본문 인라인 링크**: 본문 작성 중 언급되는 핵심 개념이나 참조가 필요한 고유 명사는 적극적으로 `[[노트이름]]`을 사용하여 링크합니다.
- **불필요한 섹션 지양**: 문서 하단에 별도의 '연결된 노트' 섹션을 만들지 않습니다.

## 4. 문서 구조화 표준

- **헤더 수준**: `#` (L1)은 문서 제목에만 단 한 번 사용하며, 본문은 `##` (L2) 이하로 구조화합니다.
- **기호 중복 금지**: 마크다운 기호를 중복해서 사용하지 않습니다. (예: `## ## 제목` (X), `## 제목` (O))
- **참고 자료**: 외부 출처나 관련 문헌이 있는 경우 문서 하단에 `## 📚 참고 자료` 섹션을 생성합니다.
    - 외부 웹사이트 링크, 논문/도서 인용 정보, 내부 첨부파일(`[[파일명.pdf]]`) 등을 불렛 포인트(`*` 또는 `-`) 리스트 형식으로 기재합니다.
    - 예시:
        ```markdown
        ## 📚 참고 자료
        * 저자명 (연도). 논문제목. *저널명*, 권(호), 페이지.
        * [웹사이트 제목](URL)
        * [[내부_참조_문서.pdf]]
        ```
- **구분선**: 주요 섹션 사이에는 `---`를 사용하여 시각적 구분을 명확히 합니다.

## 5. 파일 명명 규칙(Naming Convention)

- 파일 이름은 주제를 명확히 나타내야 합니다.
- **필수 규칙**: 새로 생성하거나 이름을 변경하는 모든 파일은 작성 연도를 접두어로 사용합니다.
- **형식**: `YYYY_주제` (예: `2025_`로 시작)
- 예: `2026_수가 개선 분석.md`, `2025_독일 출장 결과.md`

### ⚠️ 파일명 사용 금지 특수문자

#### 1. 옵시디언 링크 허용되지 않는 문자
다음 문자들은 위키링크 `[[파일명]]`에서 정상적으로 작동하지 않거나 예기치 않은 동작을 일으킬 수 있습니다:

| 문자 | 설명 | 문제 원인 |
|------|------|-----------|
| `[` `]` | 대괄호 | 위키링크 구문과 충돌 (`[[링크]]`) |
| `\|` | 파이프/수직바 | 테이블 구분자 및 별칭 구문과 충돌 |
| `#` | 해시/샵 | 태그 및 헤더 참조와 충돌 |
| `^` | 캐럿/삿갓 | 블록 ID 참조와 충돌 |
| `*` | 별표/에스터리스크 | 강조(굵게/기울임) 구문과 충돌 |
| `` ` `` | 백틱/역따옴표 | 인라인 코드 구문과 충돌 |
| `\` | 역슬래시 | 이스케이프 문자로 처리됨 |
| `>` `<` | 꺾쇠괄호 | 인용구 및 HTML 태그와 충돌 |
| `"` `"` | 따옴표 | YAML 프론트매터 파싱 문제 |

#### 2. 파일 시스템 금지 문자 (OS별)
Windows, macOS, Linux 파일 시스템에서 파일명으로 사용할 수 없는 문자:

| OS | 금지 문자 | 비고 |
|----|-----------|------|
| **Windows** | `\` `/` `:` `*` `?` `"` `<` `>` `\|` | 경로 구분자 및 와일드카드 |
| **macOS** | `:` | 볼륨 구분자로 사용 |
| **Linux/Unix** | `/` | 디렉토리 구분자 |
| **모든 OS** | `.` (마침표로 시작/끝) | 숨김 파일 또는 확장자 문제 |

#### 3. 권장 파일명 작성 규칙

```
✅ 올바른 예시:
- "2026_회의록.md"
- "2026_수가 개선 분석 보고서.md"
- "2025_독일 출장 결과.md"
- "2026_의지보조기_소켓_구조_분석.md"

❌ 잘못된 예시:
- "[보고서] 독일 출장.md" ← 대괄호 사용
- "Prosthetics|Orthotics|1999.md" ← 파이프 사용
- "수가 #개선 #분석.md" ← 해시 사용
- "2026-02-12 회의록.md" ← 대시(-) 포함된 날짜 형식 (YYYY_ 형식 권장)
- "수가 * 개선 * 분석.md" ← 별표 사용
```

#### 4. 대체 표기법
- 대괄호 대신: `(보고서)`, `{보고서}`, 또는 접두사 사용 (예: `보고서_`, `요약_`)
- 파이프 대신: `-`, `_`, `,` 사용 (예: `의지보조기-역학-분석.md`)
- 해시 대신: `_` 또는 공백 사용 (예: `수가_개선_분석.md`)
- 별표 대신: 숫자 또는 홑따옴표 사용 (예: `1차_분석.md`, `중요_문서.md`)

---

# PROS·ON 홈페이지 발행 콘텐츠 작성 규칙

이 절은 `Pros_on/콘텐츠/` 아래에 작성하는 홈페이지용 문서에 적용한다. 일반 지식 노트와 달리 홈페이지 발행 문서는 발행 API가 읽을 수 있는 frontmatter와 공개용 문장 구조를 반드시 지켜야 한다.

## 6. 홈페이지 콘텐츠 기본 경로

작성용 문서는 다음 경로에 저장한다.

```text
C:\Obsidian\LUCKY\Pros_on\콘텐츠\
├─ 01_기본안내\
├─ 02_사례\
└─ 03_뉴스\
```

- `Pros_on/콘텐츠/`: 사람이 작성하고 검토하는 원본 문서
- `Pros_on/data/posts/`: 발행 API가 저장하는 홈페이지용 결과물. 직접 작성하지 않는다.
- `.obsidian/plugins/proson-publisher/`: 현재 문서를 홈페이지로 보내는 플러그인
- 새 홈페이지 글은 반드시 `Pros_on/콘텐츠/` 아래에 만든다.

## 7. 홈페이지 발행용 필수 Properties

발행 대상 문서의 최상단에는 아래 속성을 그대로 사용한다.

```yaml
---
title: "게시글 제목"
id: "post_자동생성"
slug: "post-slug"
type: "guide"
category: "기본 안내"
tags: ["의지", "기초_안내", "사용_방법"]
description: "검색 결과와 블로그 카드에 표시할 한두 문장의 요약입니다."
published: false
publishedAt: 2026-08-06
---
```

필드 기준:

| 필드 | 필수 | 작성 원칙 |
|---|---:|---|
| `title` | 예 | 독자가 바로 이해할 수 있는 제목. 아무리 긴 수식어를 붙이지 않는다. |
| `id` | 자동 | 최초 발행 시 생성되는 내부 불변 식별자. 기존 글의 id를 변경하지 않는다. |
| `slug` | 예 | 영문 소문자·숫자·하이픈만 사용. 중복 금지. |
| `type` | 예 | `guide`, `case`, `news` 중 하나만 사용. |
| `category` | 아니오 | `기본 안내`, `사례`, `뉴스` 등 표시용 분류. |
| `tags` | 아니오 | 2~5개. `#` 없이 입력한다. |
| `description` | 예 | 1~2문장, 블로그 카드와 검색 요약에 사용. |
| `published` | 예 | 작성·검토 중에는 `false`, 공개할 때만 `true`. |
| `publishedAt` | 예 | `YYYY-MM-DD` 형식. 공개 예정일 또는 발행일. |

기존 Vault 공통 Properties인 `aliases`, `created`, `updated`, `summary`가 필요하면 함께 유지할 수 있지만, 홈페이지 발행 필드는 별도로 반드시 포함한다.

## 8. 콘텐츠 유형별 작성 기준

### `guide` 기본 안내

의지의 구성, 착용 방법, 사용 방법, 관리와 적응 등 반복적으로 안내할 내용을 작성한다.

권장 구조:

```markdown
# 의지를 처음 이해하기

한 문단 요약

## 어떤 내용인가요?

독자가 알고 싶은 핵심 내용을 설명합니다.

## 꼭 확인할 점

- 핵심 안내 1
- 핵심 안내 2

## 상담이 필요한 경우

개인별 차이가 있는 부분은 전문가 상담이 필요하다고 안내합니다.
```

### `case` 제작·착용 사례

제작 목적, 관찰 내용, 설계 방향, 제작 과정, 결과를 중심으로 작성한다.

권장 구조:

```markdown
# 생활 환경에 맞춘 의지 제작 사례

사례의 핵심 결과를 한 문단으로 요약합니다.

## 제작 배경

사용 환경과 해결하려던 불편을 개인정보 없이 설명합니다.

## 관찰과 설계

움직임을 어떻게 확인했고 어떤 방향으로 설계했는지 설명합니다.

## 제작 과정

평가, 설계, 제작, 조정의 순서로 작성합니다.

## 결과와 관리

적응 과정과 사후관리 내용을 설명합니다.
```

제작 사례와 착용 사례는 동일한 사례 문서 안에서 함께 작성한다. 제작 배경, 설계·제작 과정, 착용과 적응, 결과와 관리의 흐름으로 구성한다.

### `news` 뉴스·소식

PROS·ON의 공지, 새로운 서비스, 운영 소식, 활동 소식처럼 사례나 기본 안내에 해당하지 않는 내용을 작성한다.

권장 구조:

```markdown
# PROS·ON 새로운 소식

소식의 핵심을 한 문단으로 요약합니다.

## 어떤 소식인가요?

변경·공지·활동 내용을 설명합니다.

## 고객에게 어떤 의미가 있나요?

이 소식이 이용자에게 주는 의미를 설명합니다.
```

착용 전 준비, 착용 순서, 적응 과정, 일상에서의 변화를 중심으로 작성한다.

의학적 진단이나 개인별 치료 지시처럼 읽힐 수 있는 표현은 피하고, 구체적인 착용법은 상담이 필요하다는 문장을 포함한다.

## 9. 문체 원칙

- 전문용어는 처음 등장할 때 쉬운 말로 설명한다.
- `의지보조기`보다 브랜드가 정한 표현인 `의지`를 우선 사용한다.
- 과장 표현, 치료 효과 보장, 완치·최고·100% 등의 표현을 사용하지 않는다.
- 한 문단은 2~4문장으로 유지하고, 긴 문단은 `##` 소제목으로 나눈다.
- 한국어 단어 중간에 줄바꿈하지 않는다.
- 일반 문장에 `<br />`를 넣지 않는다.
- Wikilink(`[[문서명]]`)는 홈페이지 발행 전에 변환되지 않을 수 있으므로 공개 글에서는 일반 Markdown 링크 또는 평문을 사용한다.
- 독자가 실제로 궁금해할 질문을 제목과 소제목에 반영한다.

## 10. 이미지와 개인정보

- 이미지 파일은 문서와 함께 관리하되, 발행 전 공개 가능한 이미지인지 확인한다.
- 이름, 얼굴, 연락처, 생년월일, 병원 기록, 차트 번호 등 식별정보를 본문과 파일명에서 제거한다.
- 사례 문서는 공개 동의 여부를 확인한 뒤 `published: true`로 변경한다.
- 원본 사진을 그대로 공개하지 말고 필요한 경우 얼굴·문서·배경의 식별정보를 가린다.
- 이미지 설명에는 환자 이름 대신 `사례 이미지`, `제작 과정 이미지`처럼 작성한다.

### 10.1 블로그 이미지 스타일 가이드
- **전역 화풍 고정 수칙 (Clean High-Resolution 2D Digital Illustration)**: 앞으로 생성되는 모든 이미지(도해, 가이드, 인물, 기구 등 일체)의 화풍은 **"선명하고 매끄러운 고화질 2D 디지털 일러스트레이션 (`Clean, sharp, ultra-smooth high-resolution 2D digital vector illustration with smooth clean shading and crisp lines`)"**으로 철저히 고정한다. 거친 도트 노이즈(dot noise), 픽셀 깨짐(pixelation), 자글거리는 메시 질감, 낡은 도면 노이즈는 전면 배제한다.
- **화풍 정의 (Realistic 2D Medical Illustration)**: 너무 장난스럽거나 캐주얼한 카툰 느낌을 피하고, 정보를 신뢰감 있게 전달하기 위해 **"정교하고 현실적인 2D 메디컬 일러스트 스타일"**을 사용한다.
- **다리 및 근육 묘사**: 해부학 도감처럼 근육 섬유가 붉게 갈라지거나 과도하게 부각된 표현(Anatomical diagram style)을 전면 배제하고, **일상생활의 건강하고 자연스러운 다리 실루엣과 일반적인 피부 톤**으로 묘사한다.
- **의지(의족) 형태 및 착용 묘사**: 미래형 사이버네틱 로봇 다리 묘사를 전면 배제하고, 실제 임상에서 쓰이는 **현실적인 소켓(Socket), 커넥터/금속 튜브(Pylon)** 등의 디테일을 그리며, 다음 사항을 철저히 고증한다.
  - **하퇴의지(Transtibial, 무릎 아래 절단) vs 대퇴의지(Transfemoral, 무릎 위 절단) 구분**: 하퇴의지는 인공 무릎 장치 없이 소켓과 파이프 튜브가 환자의 실제 무릎 아래로 결합되는 형태를 정확히 묘사하고, 대퇴의지는 허벅지용 소켓 아래에 인공 무릎 관절 장치가 필수적으로 포함되는 형태를 묘사한다.
  - **핀 라이너(Pin Liner) vs 쿠션 라이너(Cushion Liner) 구분**: 핀 라이너는 라이너 끝단에 금속 핀이 있어 소켓 밑바닥 셔틀락(Shuttle lock)에 고정되는 구조(핀 노출 묘사 필요시)로 그리며, 쿠션 및 씰인 라이너(Seal-In Liner)는 끝단 핀 없이 외부 표면에 실링 밴드(Seal)가 밀착되는 수밀 흡착 방식으로 명확히 구분하여 묘사한다.
  - **발 부분**: 맨 카본 발을 노출시키는 대신 환자가 일상적으로 신는 **신발(운동화 등)을 양발 모두 신은 상태**로 묘사한다.
  - **라이너 묘사**: 의족 쪽 다리에는 일반 양말 대신 소켓 위로 올라오는 **실리콘 라이너(Silicone Liner)**를 묘사하되, **Össur 사의 Iceross Seal-In** 스타일처럼 연한 그레이/하늘색 톤의 실리콘 표면과 소켓 가장자리에 밀착하여 튀어나온 실링 링(Sealing Ring) 구조를 충실히 표현한다.
  - **무릎 구성 요소 (대퇴 절단의 경우)**: 단순 철제 힌지가 아닌 **Ottobock 사의 C-Leg 또는 3R60** 같은 현대적인 마이크로프로세서/기계식 무릎 장치의 외형 커버와 부품 실루엣을 정교하게 반영한다.
  - **구도**: 직각 측면보다는 대각선 뒤나 앞에서 바라보는 **3/4 대각선 각도(Three-quarter angled view)**의 구도를 권장한다.
- **이미지 생성 전 사전 점검 체크리스트 프로세스**:
  사용자가 이미지 생성을 단순 요청하는 경우, 곧바로 프롬프트를 작성하지 않고 **반드시 아래 체크리스트 사항을 질문하여 구체적인 정보를 확인한 뒤** 이미지를 설계 및 생성한다.
  1. **대상 부위 및 절단 수준**: 대퇴(Transfemoral)인지, 하퇴(Transtibial)인지 등 절단 부위 확인
  2. **의지 구성 상태**: 실리콘 라이너만 착용한 모습인지, 소켓 및 어댑터 부품을 포함한 완제품 의족 전체를 장착한 상태인지 확인
  3. **현수 방식 (라이너 종류)**: 핀 라이너(Pin Liner) 타입인지, 쿠션 및 씰인(Cushion/Seal-In) 타입인지 확인
  4. **피사체 표현 범위**: 전신(Head-to-toe) 묘사인지, 골반 아래 하체만 확대해서 보여주는 포커스 뷰인지 확인
  5. **신발 착용 여부**: 맨발(카본 플레이팅 풋 등) 상태인지, 양발 모두 편안한 신발(운동화)을 신은 상태인지 확인
  6. **이미지 구도**: 3/4 대각선 앵글 뷰, 정면, 측면 등 원하는 카메라 워크 확인
  7. **배경 테마**: 깔끔한 흰색 단색 배경(디폴트)인지, 재활 훈련실 내부나 야외 공원 배경인지 확인
- **모델 외형 일관성 (Character Consistency)**: 
  - 이미지 간의 일체성을 극대화하기 위해, 신규 이미지 생성 시 **`C:\Obsidian\LUCKY\Pros_on\콘텐츠\_media` 디렉토리 내에 보관되어 있는 기존 승인 완료된 최신 이미지들(사용자가 최종 고증 검증을 통과시켜 남겨둔 고증 자산)을 최우선적인 레퍼런스 참조 이미지(`ImagePaths` 매개변수)로 입력**하여 생성한다.
  - 프롬프트에도 해당 참조 이미지 속 인물의 얼굴 생김새, 단정한 짧은 검은 머리, 체격, 복장(회색 티셔츠, 남색 운동 바지) 사양의 일치성과 기하학적 형상을 계승할 것을 명시적으로 지시하여 선순환 구조를 유도한다.
  - **가상 모델 표준 프로필**: `"A friendly 30-year-old East Asian man, short neat black hair, clean-shaven, pleasant normal facial expression, average athletic build"`
  - **표준 의상 사양**: `"wearing a plain grey crew-neck t-shirt and dark blue sports shorts"`
- **색상 기준**: 브랜드 톤앤매너와 어울리는 편안하고 부드러운 색상 톤(파스텔 계열 또는 부드러운 파란색/초록색 톤)을 기본으로 사용한다. 지나치게 원색적이거나 차가운 색은 지양한다.
- **이미지 생성 프롬프트 기본 공식**:
  > `"A detailed and realistic 2D medical illustration of [주요 개체 또는 행동], showing real-world mechanical components, soft medical colors, clean shapes, professional medical design style, white background, no text, no letters, no labels, no words"`
- **이미지 파일 포맷 및 명명 규칙**:
  - 생성 및 저장되는 이미지 포맷은 웹 최적화와 범용 호환성을 보장하는 **`.jpg` 포맷을 표준으로 사용**한다. 파일 크기는 페이지 로딩 속도를 위해 1MB 이하로 최적화 및 압축하여 관리한다.
  - 이미지 파일명은 아래 패턴을 엄격히 준수하며 공백이나 대괄호 등 금지 특수문자를 사용하지 않는다.
    > `[type]-img-[YYYYMMDD]-[description]-[view/version].jpg`
    > *예시: `guide-img-20260811-bandaging-isometric.jpg`*
  - **[강제 사항] 기존 승인 완료 이미지 파일 보호 및 절대 덮어쓰기(Overwrite) 금지**:
    - 이전에 생성되어 보관된 완성작이나 시안 파일은 어떤 경우에도 덮어쓰거나 지워서는 안 된다. 
    - 수정 요구사항(예: 피팅 수정, 색상 조정, 특정 요소 크기 변화 등)이 있을 때는 반드시 파일명 끝의 접미사(`-[version/view]`, 예: `-short`, `-v2`, `-fixed` 등)를 고유하게 다르게 부여하여 **항상 새로운 파일명으로 독립된 신규 이미지를 생성 및 복사**한다. 기존 자산의 보존 상태를 100% 영구 유지해야 한다.
- **상지 의지(의수) 및 보조기(Orthotics) 확장 묘사**:
  - **상지 의지 (의수)**: 미래형 공상과학(SF) 로봇 손 디자인을 전면 배제하고, 실제 임상에서 적용되는 **현실적인 근전전동의수(Myoelectric)** 또는 실리콘 스킨의 **미용의수(Cosmetic)** 형태를 명확히 구분하여 구조적으로 고증 묘사한다.
  - **보조기 (Orthotics)**: 척추 보조기(TLSO 등)나 하지/상지 보조기 묘사 시에는 고정용 플라스틱 프레임(Thermoplastic shell), 알루미늄/스틸 지지대 및 다이얼 조인트(Joint/Bar), 벨크로 스트랩(Velcro Straps) 등 실제 부품 기계 구조를 충실히 표현한다.
- **텍스트 금지 수칙**: 이미지 내에 어떠한 문자, 영어/한국어 레이블, 제목, 치수, 포인팅 라인(지시선 및 설명 텍스트)도 포함하지 않는다. 순수 이미지 그래픽만으로 구성한다.
- **금지 요소**: 실사 사진(Real photos), 미래형 공상과학(SF) 로봇 형태, 해부학적 단면도나 붉은색 상처 표현은 사용하지 않는다.
- **이미지 분할 구성 금지 및 개별 단독 컷 원칙**:
  - 침상 자세, 재활 동작, 혹은 복수의 비교 상황을 그릴 때 하나의 이미지 파일 내부에 상하/좌우 패널을 나누는 **분할 구성(Split Panel, 예: Panel A, Panel B로 합쳐진 일러스트)을 지양**한다.
  - 다양한 웹 해상도 뷰 포트에서의 레이아웃 대응력과 활용성을 극대화하기 위해, 모든 동작과 신체 정렬 요령은 하나의 이미지 파일에 오직 한 개의 자세만 깔끔하게 노출되는 **'독립된 단일 개별 이미지(Single Individual Image)' 단위로 쪼개어 각각 별개의 파일로 생성 및 배포**한다.
- **인터랙티브 웹 모션 연동용 시퀀스(Sequence) 이미지 제작 수칙**:
  - 환자의 기기 메커니즘 이해(예: 핀라이너 착용 시 보행 수직 상하 움직임에 따라 잔존지 끝부분에 가해지는 인장 응력 작용 원리 등)를 돕기 위해 움직이는 웹 모션을 구현할 때는, 동영상이나 GIF를 직접 생성하는 대신 **움직임의 각 단계별 핵심 순간을 포착한 다단계 정적 이미지 세트(Step-by-Step Sequence)로 나누어 각각 별개의 파일로 생성**한다.
  - 이 세트 이미지들은 웹 화면 상에서 캐러셀 슬라이더(Carousel), 마우스 호버(Hover) 교차 페이드인/아웃 등의 프론트엔드 컴포넌트 기술과 유기적으로 바인딩되어 구동될 수 있도록 인물의 체격, 의상, 구도가 프레임별로 엄격하게 수평 일치해야 한다.






## 11. 발행 전 체크리스트

- [ ] 파일 위치가 `Pros_on/콘텐츠/` 아래인가
- [ ] 필수 Properties가 모두 있는가
- [ ] `slug`가 영문 소문자·숫자·하이픈으로만 구성되었는가
- [ ] `type`이 `guide`, `case`, `news` 중 하나인가
- [ ] 제목·description이 홈페이지 카드에 적절한가
- [ ] 개인정보와 공개 동의를 확인했는가
- [ ] 이미지가 공개 가능한 상태인가
- [ ] `published: false` 상태에서 먼저 검토했는가
- [ ] 검토가 끝난 후에만 `published: true`로 변경했는가
- [ ] 옵시디언에서 `현재 문서 발행`을 실행했는가
- [ ] 발행 후 `/blog/[slug]` 주소에서 확인했는가

## 12. Gemini 글 작성 요청 템플릿

Gemini에게 다음처럼 요청하면 발행 형식에 맞는 초안을 만들 수 있다.

```text
Pros_on/콘텐츠/02_제작사례/에 홈페이지 발행용 Markdown 초안을 작성해줘.

콘텐츠 유형: case
제목: [제목]
핵심 내용: [제작 목적과 결과]
공개 가능한 정보: [내용]
제외할 개인정보: 이름, 얼굴, 연락처, 생년월일, 병원명

요구사항:
1. 위 발행용 frontmatter를 포함할 것
2. type은 case로 작성할 것
3. slug는 영문 소문자·숫자·하이픈으로 만들 것
4. description은 1~2문장으로 작성할 것
5. 의지보조기 대신 의지라는 표현을 사용할 것
6. 제작 배경, 관찰과 설계, 제작 과정, 결과와 관리 순서로 작성할 것
7. 의료적 효과를 보장하거나 개인정보를 추정하는 표현을 사용하지 말 것
8. 답변은 완성된 Markdown 코드 블록 하나로만 제공할 것
```
## Pros_on 문서 파일명과 블로그 제목 규칙

Pros_on 게시글은 파일명과 독자에게 표시되는 제목을 분리한다.

### 파일명

새 게시글 파일명은 다음 패턴을 사용한다.

```text
{type}-post-{YYYYMMDD}-{sequence}.md
```

예시:

```text
case-post-20260810-01.md
guide-post-20260810-01.md
news-post-20260810-01.md
```

- `{type}`은 `case`, `guide`, `news` 중 하나다.
- 날짜는 파일을 처음 작성한 날짜다.
- 순번은 같은 날짜와 유형의 글을 구분하는 두 자리 숫자다.
- 파일명에는 공백, 한글, 환자명, 이니셜, 생년월일, 환자번호를 넣지 않는다.
- 같은 날짜와 유형의 글은 `-01`, `-02`처럼 순번을 증가시킨다.

### 블로그 제목

- 본문 첫 번째 `# 제목`을 홈페이지에 표시할 실제 블로그 제목으로 사용한다.
- `title` Properties는 첫 번째 `# 제목`과 동일하게 유지한다.
- 파일명은 관리용 식별자이므로 홈페이지 제목 문장으로 사용하지 않는다.
- `slug`는 URL 경로용 필드이며 발행 후 변경하지 않는다.
- 파일명, `title`, `slug` 어느 곳에도 환자 식별정보를 포함하지 않는다.

LLM이 새 글을 작성할 때는 위 파일명 패턴과 `# 제목`을 함께 제시하고, 발행 전에 `title`이 첫 번째 `# 제목`과 같은지 확인한다.
## Pros_on 게시 문서의 URL 규칙

- 게시 문서의 URL 식별자 속성은 `urlSlug`를 사용한다. 기존 문서의 `slug`는 읽기 호환만 유지한다.
- `urlSlug`에는 환자명, 생년월일, 차트번호, 주문번호 등 개인정보를 포함하지 않는다.
- 값은 영문 소문자와 숫자, 하이픈만 사용하며 짧고 일관된 kebab-case로 작성한다.
- 블로그 제목은 frontmatter의 `title`보다 본문의 첫 번째 `# 제목`을 기준으로 작성한다. 파일명은 `case-post-YYYYMMDD-01.md`처럼 짧은 규칙을 따른다.

## 14. 블로그 게시용 어휘 및 문구 작성 규칙
- **독자 배려**: 처음 절단 수술을 경험한 환자나 가족이 안심하고 읽을 수 있도록 친절하고 신뢰감을 주는 어조(경어체)를 사용한다.
- **정보 전달 목적성**: 환부 관리, 관절 구축 예방 등 예민한 주제를 다룰 때는 비전문가도 쉽게 행동 지침을 이해할 수 있게 명확하고 간결한 어휘를 선택한다.
- **의학적 과장 금지**: '완치', '100% 효과 보장', '가장 완벽한' 등 과장되거나 의료적 오해를 부를 수 있는 단어는 피하고, 전문가 상담이 동반되어야 함을 분명히 어휘와 어조로 밝힌다.
- **정확한 용어 사용 및 비전문가 친화적 순화**:
  - '의지보조기' 대신 대중적으로 친숙한 **'의지' 또는 '의족'**이라는 표현을 일관되게 사용한다.
  - 환자와 가족이 읽기에 지나치게 어렵거나 낯선 전문 의학/임상 용어(예: 구축, 현수, 원위부, 슬관절, 앙와위/복와위 등)를 기술할 때는 반드시 최초 노출 시 일반인의 눈높이에 맞게 한글로 풀어서 설명하거나 보조 설명을 괄호 안에 의무적으로 덧붙인다.
    - *예시: `잔존지(절단 후 남은 다리 부위)`, `관절 구축(관절이 굳어지는 현상)`, `현수 방식(의족이 다리에서 빠지지 않게 고정하는 방식)`, `원위부(끝부분)`, `슬관절(무릎 관절)`, `앙와위(똑바로 눕는 자세) / 복와위(엎드리는 자세)`*
- **의지보조기기사(P&O) 관점의 서술**: 블로그 운영 주체가 의지 제작 및 설계의 전문가인 '의지보조기기사'이므로, 치료나 수술 등 의사의 진단 영역에 대한 직접 언급은 피하고 **'의지의 설계·제작 과정, 잔존지 상태 분석을 통한 적합(Fitting) 훈련, 올바른 관리 및 착용 요령'**에 전문성을 둔 표현으로 서술한다.
- **의족 부위 및 현수 방식(라이너) 서술의 전문성**:
  - 글 작성 시 환자의 절단 부위에 따라 **하퇴의지(종아리 부위 절단)**와 **대퇴의지(허벅지 부위 절단)**를 용어와 특성 면에서 명확히 구분하여 서술한다.
  - 환자가 착용하는 실리콘 라이너도 끝단에 고정 핀이 달린 **핀 라이너(Pin Liner)** 방식과, 핀 없이 흡착식 실(Seal)이나 슬리브로 진공을 유지하는 **쿠션 라이너(Cushion Liner) / 씰인 라이너(Seal-In Liner)** 방식을 정확히 구분하여 독자에게 안내한다.
- **공식 재활 교육 자료 참조 필수 규정**: 
  - 블로그 내에서 **재활 훈련 방법, 환부(잔존지) 관리 요령, 압박 붕대 감기, 관절 구축 예방 운동, 피부 위생 수칙** 등 환자 교육 및 신체 관리와 관련된 모든 임상 정보를 서술할 때는 반드시 **`30. Area/교육 자료 및 학술` 디렉토리 하위에 위치한 전문 임상 가이드 및 첨부 자료들을 전반적으로 정독 및 참조하여 작성**해야 한다.
  - **[MOC 인덱스 1순위 참조 규칙]**: 무분별한 폴더 전체 스캔에 따른 토큰 낭비와 비효율성을 방지하기 위해, 자료 검증 및 참고 시 우선적으로 **`30. Area/교육 자료 및 학술/교육 자료 및 학술 인덱스 (MOC).md` 인덱스 문서를 1순위로 열어 조망**하고, 해당 맵 내에서 필요한 구체적인 의학 파일의 상대 경로 링크를 탐색하여 정독 및 교차 검증을 실행한다. 검증되지 않은 일반 상식 서술을 금지하며 이 MOC 맵 기반 검증을 기준으로 삼는다.
  - **[중요] 출처 기관명 노출 금지 수칙**: 해당 블로그는 **개인 의지보조기기사가 운영하는 전문 블로그**이므로, 글 본문이나 면책조항(Disclaimer)에 '재활의학연구센터', '근로복지공단' 등 특정 외부 공공기관이나 소속 단체의 이름을 직접적으로 명시·노출해서는 안 된다. 출처 언급 시 **"표준적인 임상 재활 가이드라인"** 혹은 **"학술적 임상 지침"**과 같이 보편적이고 신뢰감을 주는 중립적 어휘로 완화하여 작성한다.
- **[재활의학연구센터 간호교육 ver1.1] 임상 고증 표준 지침**:
  - **실리콘 라이너 착용법**: 일반 스타킹처럼 잡아당겨 신지 않고, **안팎을 뒤집은 후 잔존지 원위부(끝단)에 공기 없이 완전히 밀착시킨 다음, 롤온(Roll-on) 방식으로 균등하게 굴려 올려 착용**하는 행위를 묘사하고 서술한다.
  - **탄력 붕대법 (Stump Bandaging)**: 8자형 감기(Figure-of-eight)를 기본으로 하며, 원위부(끝)에 가장 높은 압력을 주고 근위부(위)로 갈수록 느슨하게 감는다. 하퇴 절단은 4인치 붕대 2~3개를 사용하여 무릎 위까지 감아 올리며, 대퇴 절단은 6인치 2개/4인치 1개 붕대를 활용하여 사타구니와 허리까지 8자형으로 둘러 감는다. 대퇴 붕대법 묘사 시 앉은 자세가 아닌 서거나 옆으로 누운 자세로 묘사한다.
  - **침상 자세 (구축 예방)**: 앙와위(똑바로 눕기) 시 절단단 아래에 베개 사용을 절대 피하도록 지시한다. 고관절/슬관절 신전을 유도하기 위해 하루 30분씩 2회 또는 15분씩 4회 복와위(엎드려 눕기) 자세를 수행하도록 묘사한다.
  - **피부 및 위생 관리**: 취침 전 보습로션을 적용하되 의지 착용 직전에는 보습로션을 바르지 않도록 안내하며, 손거울을 활용하여 매일 잔존지 뒷부분과 말단부 피부의 상처/발적을 살피는 행동을 묘사한다.
- **웹 호환성을 고려한 이모티콘 및 특수 기호 사용 제한**:
  - 작성되는 포스트는 최종적으로 홈페이지 웹 환경에 퍼블리싱되는 글이므로, 운영체제(OS)나 브라우저에 따라 깨지거나 올바르게 렌더링되지 않을 수 있는 컬러 이모지(Emoji, 예: 💡, ❌, 📌 등)의 무분별한 사용을 엄격히 금지한다.
  - 가시성을 강조하고 싶을 때는 이모지 대신 마크다운 굵은 글씨(`**굵게**`), 인용문 blockquote(`>`), 또는 표준 텍스트 기호(`*`, `-`, `[참고]`, `[주의]`)를 사용하여 안정적인 웹 호환성과 표준 타이포그래피 품질을 유지한다.
- **이미지 생성 대기 플레이스홀더 및 TODO.md 연동 프로세스**:
  - 글 작성 중 본문에 설명 보완용 이미지가 신규로 기획되거나 당장 삽입하지 못할 때(예: API 한도 초과, 임상 디자인 확정 대기 등)는 글을 멈추지 않고 아래 **이중 동기화 프로토콜**을 적용한다.
    1. **본문 내 플레이스홀더 기입**: 삽입 대상 위치에 명확한 설명과 파일명을 담은 HTML 주석 플레이스홀더를 삽입하여 앵커를 잡아둔다.
       - *양식: `<!-- TODO: [이미지 대기] [상세 설명 및 대상 내용] (파일명: guide-img-YYYYMMDD-[name].jpg) -->`*
    2. **TODO.md 즉시 연동**: 해당 주석 앵커를 생성하는 즉시 프로젝트 루트의 `TODO.md` 파일의 `⏳ 대기 중인 이미지 생성 작업` 하위 및 관련 카테고리 체크리스트에 **생성 경로, 참조 파일, 모델 특징, 임상 고증 요건**을 명시하여 할 일을 등록한다.
    3. **동작**: 할당량이 해제되거나 조건이 충족되어 이미지가 최종 생성되면 주석 코드를 해당 마크다운 이미지 태그(`![설명](../_media/파일명.jpg)`)로 교체하여 완성한다.
- **가이드 및 사례 포스트 최적 글자수 준수 규칙**:
  - 전문적이고 신뢰성 높은 의학/재활 지식을 풍부하게 담고, 검색 엔진 최적화(SEO) 노출 점수를 극대화하기 위해 포스트당 **공백 포함 3,000자 내외(최소 2,500자 ~ 최대 3,500자)** 분량을 목표로 서술한다.
  - 단순 요약 나열식 서술을 지양하고, H2, H3 제목 태그를 구조적으로 활용하여 임상적 근거, 자가 치료 방법, 단계별 실천 행동 지침을 상세히 채워 분량과 전문성 깊이를 동시에 확보한다.
- **브랜드 중립성 확보를 위한 다수 제조사 제품 교차 병기 추천 규칙**:
  - 특정 제조사나 유통사의 제품 한 가지만을 일방적으로 몰아주어 추천하는 식의 광고성 서술을 엄격히 배제한다.
  - 가이드라인이나 자가진단 포스팅 등에서 예시 제품을 추천 및 언급할 때는, 특정 브랜드(예: 오토복)의 제품 하나만 명시하지 않고, 동급 기술군을 가진 다수 글로벌 제조사(예: 오서, 필라우어, 윌로우우드 등)의 대표 제품명을 최소 2개 이상 동등한 지분으로 함께 묶어 소개한다.
    - *예시 서술:* `"고탄성 카본 발 기술이 탑재된 의족 발(예: 오토복의 Taleo 또는 오서의 Pro-Flex 등)을 고려할 수 있습니다."*, `"컴퓨터 제어식 마이크로프로세서 무릎(예: 오토복의 C-Leg 또는 오서의 Rheo Knee 등)이 대안이 될 수 있습니다."*