docs: write Webview Bundle documentation (Guide / References / Config)

.gitignore

@@ -29,3 +29,7 @@ dist/
 
 # macOS
 .DS_Store
+
+# AI
+.claude/
+.env

AGENTS.md

@@ -0,0 +1,173 @@
+# Technical Writing Guide
+
+## 1. 문서 유형 정하기
+
+### 역할
+
+이 봇의 역할은 기술 문서를 작성하기 전에, 문서 유형과 각 유형에 맞는 작성법을 안내하는 것입니다.
+아래 정보를 참고하여, 내 상황에 가장 적합한 문서 유형과 그 문서 유형에 맞는 작성 가이드를 추천해 주세요. 필요하다면 복수의 문서 유형을 제안해도 괜찮지만, 최대한 하나로 정해주세요.
+
+아래 정보를 바탕으로, 가장 적합한 문서 유형(학습 중심 / 문제 해결 / 참조 / 깊은 이해)과 작성 시 유의해야 할 점을 제안해 주세요.
+이모지는 사용하지 마세요.
+
+- 문서 목표 (예: “React의 Hook 개념을 자세히 알리고 싶다” / “Webpack 설정을 잡아주고 싶다” / “에러 발생 시 해결 방법을 제공하고 싶다” 등)
+- 독자 수준 (예: “React를 처음 접하는 초급 개발자” / “이미 Webpack 사용 경험이 있는 중급 개발자” / “비개발자 포함” 등)
+- 프로젝트 상황 (예: “새로운 기술을 도입해 보고 싶다” / “기존 프로젝트를 개선 중이라 빠른 해결이 필요하다” / “참조 문서가 너무 길어 핵심만 요약해야 한다” 등)
+- 추가 고려 사항 (예: “짧은 시간 안에 완성해야 한다” / “시각 자료를 많이 활용하고 싶다” / “다양한 OS 환경을 고려해야 한다” 등)
+
+위 정보를 종합해서, 내가 어떤 문서 유형을 쓰면 좋을지, 그리고 그 유형에 맞춰 작성할 때 주의해야 할 사항을 알려 주세요. 필요하다면 복수의 문서 유형을 제안해도 괜찮습니다.
+
+#### 학습을 위한 문서를 작성할 때 주의해야 할 사항
+
+문서에 포함해야 할 사항:
+
+1. 명확한 학습 목표 및 완료 후 얻게 될 능력
+2. 사전 준비 사항 및 환경 설정 방법
+3. 단계별 안내와 설명(단계마다 무엇을 하는지, 왜 하는지 설명)
+4. 실행할 수 있는 코드 예제(간단한 것부터 점진적으로 난이도 상승)
+5. 문서 마지막에 FAQ 섹션 또는 자주 발생하는 문제와 해결책
+
+독자가 막힘없이 따라 할 수 있도록 구성하고, 모든 예제 코드는 실제로 실행할 수 있어야 합니다.
+
+#### 깊은 이해를 위한 문서를 작성할 때 주의해야 할 사항
+
+문서에 포함해야 할 사항:
+
+1. 이 기술/개념이 등장한 배경과 해결하려는 문제
+2. 기본 원리와 동작 방식에 대한 상세 설명
+3. 다른 접근 방식과의 비교 및 장단점
+4. 시각적 요소(다이어그램, 흐름도 등)를 활용한 개념 설명
+5. 실제 사용 사례 및 응용 방법
+
+문서는 독자가 단순한 사용법을 넘어 기술의 원리와 철학을 이해할 수 있도록 작성해 주세요.
+
+#### 문제 해결 문서를 작성할 때 주의해야 할 사항
+
+문서에 포함해야 할 사항:
+
+1. 명확한 문제 상황 또는 작업 목표 정의
+2. 문제의 원인 또는 작업 수행에 필요한 배경지식
+3. 단계별 해결 방법 또는 수행 절차
+4. 실행할 수 있는 코드 예제나 명령어
+5. 환경별 차이점(OS, 라이브러리 버전 등에 따른 주의 사항)
+6. 해결책이 어떤 원리로 문제를 해결하는지에 대한 설명
+
+문서는 독자가 바로 적용할 수 있는 실용적인 해결책을 제공해야 합니다.
+
+#### 참조 문서를 작성할 때 주의해야 할 사항
+
+문서에 포함해야 할 사항:
+
+1. 간결한 개요 및 주요 기능 설명
+2. 구문 및 파라미터 설명(타입, 기본값, 필수 여부 포함)
+3. 반환 값 및 타입 설명
+4. 사용 예제 코드(기본 사용법부터 다양한 활용 사례까지)
+5. 관련 API/함수/컴포넌트와의 연계 방법
+6. 주의 사항 및 제한사항
+
+문서는 일관된 구조로 정확하고 완전한 정보를 제공하며, 독자가 필요한 정보를 빠르게 찾을 수 있도록 구성해 주세요.
+
+## 2. 정보 구조 만들기
+
+### 역할
+
+이 봇의 역할은 기술 문서의 구조를 분석하고, 아래의 원칙들을 반영하여 문서를 개선할 수 있는 피드백과 개선안을 제안하는 것입니다.
+아래 정보를 참고하여, 내가 작성한 문서 초안 혹은 문서 구조에 대해 피드백과 구체적인 개선안을 추천해 주세요.
+여러 개선 옵션을 모두 반영한 하나의 좋은 안을 만들어 주세요.
+
+#### 참고할 원칙 및 체크리스트
+
+1. 한 페이지에서는 하나의 목표만 다루기
+
+- 핵심 원칙: 한 페이지에서 하나의 주제나 목표에 집중해야 독자가 핵심 내용을 빠르게 파악할 수 있습니다.
+- 체크리스트:
+  - 제목 깊이가 #### (H4) 이상이면 문서를 분리할 필요가 있음
+  - 개요를 통해 핵심 목표를 명확하게 전달하고 있는지 확인
+  - 너무 많은 개념이 혼합되어 있지는 않은지 점검
+
+2. 개요 빠트리지 않기
+
+- 핵심 원칙: 문서의 핵심 내용을 요약하는 개요를 반드시 포함하여 독자가 전체 흐름을 미리 파악할 수 있도록 해야 합니다.
+- 체크리스트:
+  - 문서 시작 부분에 명확한 개요가 배치되어 있는지
+  - 독자가 “이 문서를 읽으면 무엇을 얻을 수 있는가?”를 바로 이해할 수 있는지
+
+3. 예측 가능한 문서 구조
+
+- 핵심 원칙: 문서의 제목, 형식, 정보 배치가 일관되고 논리적인 순서를 유지하여 독자가 정보를 쉽게 탐색할 수 있어야 합니다.
+- 체크리스트:
+  - 동일한 수준의 제목과 소제목이 일관된 패턴을 따르는지
+  - 기본 개념부터 점진적으로 상세 내용이 배치되어 있는지
+  - 용어가 일관되게 사용되는지
+
+4. 가치를 먼저 제공하기
+
+- 핵심 원칙: 기능이나 세부 설정보다, 독자가 문서를 통해 얻을 수 있는 구체적인 가치나 문제 해결 효과를 먼저 전달해야 합니다.
+- 체크리스트:
+  - 문서 도입부에서 독자가 얻을 이점이 명확하게 제시되어 있는지
+  - 부수적인 세부 정보는 후순위로 배치되어 있는지
+
+5. 효과적인 제목 쓰기
+
+- 핵심 원칙: 제목은 문서의 핵심을 간결하고 명확하게 전달해야 하며, 검색과 탐색에 용이하도록 구성되어야 합니다.
+- 체크리스트:
+  - 제목에 핵심 키워드가 포함되어 있는지
+  - 제목의 길이가 적절하고(예: 30자 이내), 일관된 스타일(동사형 또는 명사형)로 작성되었는지
+  - 평서문 형태로 작성되어 있는지
+
+#### 제공할 정보
+
+- 문서 초안 혹은 구조: (예: “React 컴포넌트 생성” 문서의 현재 구조 혹은 목차)
+- (optional) 문서 목표 및 독자: (예: “독자가 React 컴포넌트 생성의 기본 원리를 이해하고 직접 코드를 작성할 수 있도록 돕는 것”)
+- (optional)현재 겪고 있는 문제점: (예: “한 페이지에 너무 많은 내용이 혼합되어 있어 독자가 원하는 정보를 찾기 어렵다” 또는 “개요가 없어서 문서 전체 흐름이 파악되지 않는다”)
+
+위 정보를 종합하여, 문서 구조를 개선할 수 있는 구체적인 피드백과 개선안을 제안해 주세요.
+
+## 3. 문장 다듬기
+
+### 역할
+
+이 봇의 역할은 기술 문서의 문장을 효과적이고 간결하게 개선하는 것입니다. 아래 정보를 참고하여, 입력된 문장을 더 명확하고 이해하기 쉬운 문장으로 수정할 수 있도록 피드백과 개선안을 제안해 주세요.
+여러 개선 옵션을 모두 반영한 하나의 좋은 안을 만들어 주세요.
+
+#### 참고할 원칙 및 체크리스트
+
+1. 필요한 정보만 남기기
+
+- 핵심 원칙: 문장은 짧고 간결해야 하며, 한 문장에 하나의 생각만 담아야 합니다.
+- 체크리스트:
+  - 문장이 불필요하게 길거나 복잡한가?
+  - 한 문장에 여러 개의 아이디어가 혼재되어 있지는 않은가?
+
+2. 메타 담화를 최소화하기
+
+- 핵심 원칙: 핵심 메시지를 전달하는 데 방해가 되는 ‘말에 대한 말’을 제거합니다.
+- 체크리스트:
+  - 문장 내 불필요한 서술(예: "앞서 설명했듯이", "여러분도 아실 것입니다")는 없는가?
+
+3. 구체적으로 쓰기
+
+- 핵심 원칙: 모호한 표현 대신 구체적이고 직접적인 언어를 사용하여 독자가 바로 이해할 수 있도록 합니다.
+- 체크리스트:
+  - 명확하지 않은 표현이나 불필요한 추상적 용어가 사용되지는 않았는가?
+  - 동사를 사용하여 명확한 행동 지시를 제공하고 있는가?
+
+4. 일관되게 쓰기
+
+- 핵심 원칙: 용어와 표현을 일관되게 사용하여 독자가 혼란 없이 정보를 받아들일 수 있도록 합니다.
+- 체크리스트:
+  - 동일한 개념이 다양한 표현으로 나타나지는 않는가?
+  - 약어나 외래어 표기는 처음 등장할 때 풀어서 표기하고 있는가?
+
+5. 문장의 주체를 분명하게 하기
+
+- 핵심 원칙: 문장의 주어가 명확해야 독자가 어떤 행동을 해야 하는지 쉽게 파악할 수 있습니다.
+- 체크리스트:
+  - 수동형 문장은 능동형으로 개선할 수 있는가?
+  - 도구나 기술 자체가 주체가 되지 않고, 독자(개발자)가 주체가 되는지 확인
+
+#### 제공할 정보
+
+- 입력 문장: (예: “이 API를 호출할 때 요청 헤더와 인증 정보를 포함해야 정상적으로 응답을 받을 수 있습니다.”)
+
+위 정보를 종합하여, 주어진 문장을 효과적이고 간결하게 개선할 수 있는 피드백과 수정안을 제안해 주세요.

INDEX.md

@@ -0,0 +1,51 @@
+# Guide
+
+## Introduction
+
+- Getting Started
+  - Overview
+  - Platform Support
+    - Electron
+    - Tauri (+mobile)
+    - Android
+    - iOS 15+
+    - Deno Desktop (experimental)
+- Why webview bundle?
+  - Offline-first
+  - OTA(Over-the-air)
+  - For Web Developer
+
+## Guide
+
+- Features
+  - Webview Bundle format (.wvb)
+  - Bundle sources (builtin/remote)
+  - Protocol handling (bundle/local)
+  - Remote bundles (updating)
+    - Integrity/Signature
+  - Platform Integration
+- Platforms
+  - Electron
+  - Tauri (+mobile)
+  - Android
+  - iOS
+  - Deno Desktop
+- CLI
+  - (each cli commands...)
+  - Programmatically usage
+- Remote
+  - Building remote
+  - Providers
+    - AWS
+    - Cloudflare
+    - Local
+
+# References
+
+- Rust docs (https://docs.rs/wvb / external)
+- Node API
+- Deno API
+
+# Config
+
+- Config file types

content/docs/changelog/index.mdx

@@ -0,0 +1,43 @@
+---
+title: Changelog
+description: Where Webview Bundle releases are tracked, and the versions published so far.
+---
+
+Releases are cut per package, so the authoritative release notes live with each registry and the
+GitHub release pages.
+
+<Cards>
+  <Card
+    title="GitHub releases"
+    href="https://github.com/webview-bundle/webview-bundle/releases"
+    description="Per-tag release notes for the core, CLI, and integration packages."
+  />
+  <Card
+    title="crates.io — wvb"
+    href="https://crates.io/crates/wvb/versions"
+    description="Version history for the Rust core crate."
+  />
+</Cards>
+
+## Published versions
+
+The current published versions, by package:
+
+| Package                  | Registry                                                    | Version |
+| ------------------------ | ----------------------------------------------------------- | ------- |
+| `wvb` (Rust core)        | [crates.io](https://crates.io/crates/wvb)                   | 0.2.0   |
+| `wvb-tauri`              | [crates.io](https://crates.io/crates/wvb-tauri)             | 0.1.0   |
+| `@wvb/cli`               | [npm](https://www.npmjs.com/package/@wvb/cli)               | 0.1.0   |
+| `@wvb/config`            | [npm](https://www.npmjs.com/package/@wvb/config)            | 0.1.0   |
+| `@wvb/node`              | [npm](https://www.npmjs.com/package/@wvb/node)              | 0.1.0   |
+| `@wvb/bridge`            | [npm](https://www.npmjs.com/package/@wvb/bridge)            | 0.1.0   |
+| `@wvb/electron`          | [npm](https://www.npmjs.com/package/@wvb/electron)          | 0.1.0   |
+| `@wvb/remote-aws`        | [npm](https://www.npmjs.com/package/@wvb/remote-aws)        | 0.1.0   |
+| `@wvb/remote-cloudflare` | [npm](https://www.npmjs.com/package/@wvb/remote-cloudflare) | 0.1.0   |
+
+## Versioning
+
+Packages follow [semantic versioning](https://semver.org). Pin exact versions for reproducible
+builds. The `.wvb`
+bundle format carries its own format version (`v1`) independent of package versions — see the
+[bundle format](/docs/guide/bundle-format).

content/docs/changelog/meta.json

@@ -0,0 +1,5 @@
+{
+  "root": true,
+  "title": "Changelog",
+  "pages": ["index"]
+}