@handsupmin/gc-tree 0.1.3 → 0.1.4

package/docs/concept.ko.md

@@ -1,52 +1,52 @@
-# 컨셉
+# 개념
 
 [English](concept.md) | [한국어](concept.ko.md) | [简体中文](concept.zh.md) | [日本語](concept.ja.md) | [Español](concept.es.md)
 
-## Summary
+## 요약
 
-`gctree`는 AI 코딩 도구를 위한 작고 명확한 글로벌 컨텍스트 레이어입니다. 장기적으로 유지할 컨텍스트를 단일 저장소 바깥의 markdown 문서로 관리하고, gc-branch 단위로 전환·조회·유지할 수 있으며, 실제로 관련 있는 레포에만 적용되도록 범위를 제한할 수도 있습니다.
+`gctree`는 AI 코딩 도구를 위한 가벼운 글로벌 컨텍스트 레이어입니다. 하나의 레포 밖에서 장기 컨텍스트를 명시적인 markdown 문서로 관리하고, gc-branch를 바꿔가며 맥락을 나눠 쓸 수 있게 해주며, 각 gc-branch가 실제로 관련 있는 레포에서만 적용되도록 제한할 수 있습니다.
 
-## `gctree`란
+## `gctree`는 무엇인가
 
-`gctree`는 재사용 가능한 글로벌 컨텍스트를 관리하기 위한 경량 CLI입니다.
-여러 저장소, 세션, 도구를 오가더라도 같은 장기 컨텍스트를 일관되게 이어가야 하는 팀과 개인을 위해 만들어졌습니다.
+`gctree`는 재사용 가능한 글로벌 컨텍스트를 관리하는 CLI입니다.
+여러 레포, 여러 세션, 여러 도구를 오가더라도 장기 컨텍스트가 사라지지 않게 하되, 그 컨텍스트가 숨겨진 메모리처럼 블랙박스에 갇히지 않도록 설계했습니다.
 
-장기 지식을 숨겨진 메모리에 맡기거나 여러 프롬프트 파일에 흩어 두는 대신, `gctree`는 그 지식이 머무를 안정적인 파일 기반 홈을 제공합니다.
+중요한 지식이 프롬프트 파일, 레포 내부 메모, 임시 지시문으로 흩어지는 대신, `gctree`는 그 지식이 머물 수 있는 안정적인 파일 기반 저장소를 제공합니다.
 
-## 해결하는 문제
+## 어떤 문제를 해결하나
 
-많은 AI 코딩 환경은 보통 다음 중 하나로 시작합니다.
+많은 AI 코딩 환경은 이렇게 작게 시작합니다.
 
-- 하나의 `AGENTS.md`
-- 하나의 `CLAUDE.md`
-- 저장소 내부의 프롬프트 파일
-- 프롬프트에 복붙하는 임시 메모
+- `AGENTS.md` 하나
+- `CLAUDE.md` 하나
+- 레포 안의 짧은 프롬프트 파일 하나
+- 필요할 때마다 프롬프트에 복붙하는 메모 몇 개
 
-처음에는 이 정도로도 충분하지만, 시간이 지나면 이런 요구가 생깁니다.
+처음에는 잘 돌아갑니다. 하지만 실제 업무가 얹히기 시작하면 금방 틀어집니다.
 
-- 제품이나 고객사별로 컨텍스트를 분리하고 싶다
-- 특정 저장소 바깥에서도 유지되는 컨텍스트가 필요하다
-- 여러 도구가 함께 재사용할 수 있는 장기 문서가 필요하다
-- 필요한 컨텍스트를 빠르게 찾는 일관된 방식이 필요하다
-- 장기 컨텍스트를 더 안전하게 업데이트하고 싶다
-- 한 사용자가 동시에 여러 레포/세션에서 병렬 작업을 한다
+- 제품마다 필요한 컨텍스트가 다르다
+- 고객사 작업은 서로 섞이면 안 된다
+- 재사용 가능한 가이드는 특정 레포 바깥에 있어야 한다
+- 여러 도구가 같은 source of truth를 읽을 수 있어야 한다
+- 장기 컨텍스트는 안전하고 검토 가능한 흐름으로 업데이트되어야 한다
+- 한 사람이 동시에 여러 레포에서 여러 세션을 돌릴 수 있다
 
-`gctree`는 바로 그 레이어를 다룹니다.
+`gctree`는 바로 그 레이어를 깔끔하게 해결하려고 존재합니다.
 
 ## 범위 경계
 
-`gctree`는 의도적으로 다음 역할을 맡지 않습니다.
+`gctree`는 의도적으로 다음이 아닙니다.
 
-- request-to-commit 딜리버리 오케스트레이터
+- 요청부터 커밋까지 전 과정을 오케스트레이션하는 배달 시스템
 - 숨겨진 메모리 시스템
 - 브라우저 기반 협업 런타임
-- 범용 지식베이스 제품
+- 범용 지식 베이스 제품
 
-`gctree`는 재사용 가능한 글로벌 컨텍스트 브랜치와 명시적인 업데이트 흐름에 집중합니다.
+`gctree`는 한 가지 일에 집중합니다. 재사용 가능한 글로벌 컨텍스트 브랜치를 관리하고, 그 변경을 명시적으로 다루는 일입니다.
 
-## 파일 구조
+## 파일 모델
 
-일반적인 홈 디렉터리 구조는 다음과 같습니다.
+보통 홈 디렉터리 아래 구조는 이렇게 생깁니다.
 
 ```text
 ~/.gctree/
@@ -60,22 +60,22 @@
       docs/
 ```
 
-- `HEAD`는 fallback 활성 gc-branch를 가리킵니다.
-- `settings.json`은 provider 모드, 실제 온보딩에 사용할 provider, 선호 워크플로 언어를 저장합니다.
-- `branch-repo-map.json`은 gc-branch별 include/exclude 레포 규칙을 저장합니다.
-- `branch.json`은 가벼운 gc-branch 메타데이터를 저장합니다.
-- `index.md`는 도구가 읽는 작은 진입점입니다.
-- `docs/`는 source-of-truth markdown 문서를 보관합니다.
+- `HEAD`는 기본으로 활성화되는 gc-branch를 가리킵니다.
+- `settings.json`에는 provider 모드, 런타임 시작에 사용할 온보딩 provider, 선호 워크플로 언어가 저장됩니다.
+- `branch-repo-map.json`에는 각 gc-branch별로 어떤 레포를 포함하거나 제외할지 저장됩니다.
+- `branch.json`에는 가벼운 gc-branch 메타데이터가 들어갑니다.
+- `index.md`는 도구가 먼저 들어오는 압축된 진입점입니다.
+- `docs/`에는 source-of-truth markdown 문서가 들어갑니다.
 
-## 레포 범위 인식 동작
+## 레포 인식 동작
 
-어떤 gc-branch가 모든 레포에 적용될 필요는 없습니다.
-예를 들어 branch `A`가 `B`, `C`, `D` 레포에만 관련 있다면, 그 사실을 `branch-repo-map.json`에 기록할 수 있습니다.
+gc-branch는 모든 곳에 적용될 필요가 없습니다.
+예를 들어 `A` 브랜치가 `B`, `C`, `D` 레포에서만 의미가 있다면, `gctree`는 그 사실을 `branch-repo-map.json`에 기록할 수 있습니다.
 
-그 상태에서 `F` 레포에서 `gctree resolve`가 호출되면 다음 중 하나를 고를 수 있습니다.
+그 상태에서 다른 레포인 `F`에서 `gctree resolve`를 실행하면, 다음처럼 처리할 수 있습니다.
 
-- 이번만 사용
-- 이 레포에서 항상 사용
-- 이 레포에서는 무시
+- 이번 한 번만 계속하기
+- 앞으로 `F`에서도 그 gc-branch를 항상 사용하기
+- `F`에서는 그 gc-branch를 무시하기
 
-이 구조 덕분에, 동시에 여러 세션을 열고 서로 다른 레포를 다루는 heavy 사용자에게도 더 안전해집니다.
+이 덕분에 서로 무관한 레포들 사이에서 여러 세션을 동시에 많이 띄워두는 사용자에게도 gc-tree가 훨씬 안전하게 동작합니다.

package/docs/concept.md

@@ -4,34 +4,34 @@
 
 ## Summary
 
-`gctree` is a lightweight global-context layer for AI coding tools. It keeps durable context in explicit markdown documents outside any single repository, lets users switch between gc-branches, and can restrict each gc-branch to the repositories where it actually applies.
+`gctree` is a lightweight global-context layer for AI coding tools. It keeps long-lived context in explicit markdown documents outside any single repository, lets you switch between gc-branches, and can limit each gc-branch to the repositories where it actually belongs.
 
 ## What `gctree` is
 
 `gctree` is a CLI for managing reusable global context.
-It is designed for teams and individuals who want long-lived context to survive across repositories, sessions, and tools without turning that context into hidden memory.
+It is built for people and teams who want important context to survive across repositories, sessions, and tools without turning into hidden memory.
 
-Instead of scattering important knowledge across prompt files, repo-local notes, and ad hoc instructions, `gctree` gives that knowledge a stable, file-backed home.
+Instead of scattering key knowledge across prompt files, repo-local notes, and one-off instructions, `gctree` gives that knowledge a stable, file-backed place to live.
 
 ## What problem it solves
 
-Many AI coding setups start small:
+A lot of AI coding setups start small:
 
 - one `AGENTS.md`
 - one `CLAUDE.md`
 - one repo-local prompt file
-- a handful of notes copied into prompts as needed
+- a few notes copied into prompts when needed
 
-That works for a while. Then the same setup starts to break under real-world needs:
+That works for a while. Then real work shows up and the cracks start to show:
 
 - different products need different context
-- client work must stay isolated
+- client work needs clean isolation
 - reusable guidance should live outside any single repository
 - multiple tools should be able to read the same source of truth
-- long-lived context should evolve through a safe, reviewable flow
-- one user may run many sessions across many repositories at the same time
+- long-lived context should change through an explicit, reviewable flow
+- one person may have many sessions open across many repositories at once
 
-`gctree` exists to solve that layer cleanly.
+`gctree` exists to handle that layer cleanly.
 
 ## Scope boundary
 
@@ -42,7 +42,7 @@ That works for a while. Then the same setup starts to break under real-world nee
 - a browser collaboration runtime
 - a general-purpose knowledge base product
 
-It focuses on one job: managing reusable global-context branches and explicit updates.
+It focuses on one job: managing reusable global-context branches and explicit durable updates.
 
 ## File model
 
@@ -65,12 +65,12 @@ A typical home directory looks like this:
 - `branch-repo-map.json` stores which repositories are included or excluded for each gc-branch.
 - `branch.json` stores lightweight gc-branch metadata.
 - `index.md` is the compact entry point for tools.
-- `docs/` holds source-of-truth markdown documents.
+- `docs/` holds the source-of-truth markdown documents.
 
 ## Repo-aware behavior
 
-A gc-branch does not have to apply everywhere.
-If branch `A` is only relevant to repositories `B`, `C`, and `D`, `gctree` can record that in `branch-repo-map.json`.
+A gc-branch does not need to apply everywhere.
+If branch `A` only matters to repositories `B`, `C`, and `D`, `gctree` can record that in `branch-repo-map.json`.
 
 When `gctree resolve` runs in another repository such as `F`, it can:
 
@@ -78,4 +78,4 @@ When `gctree resolve` runs in another repository such as `F`, it can:
 - always use that gc-branch in `F`
 - ignore that gc-branch in `F`
 
-This makes gc-tree much safer for heavy users who keep many parallel sessions open across unrelated repositories.
+That makes gc-tree much safer for heavy users who keep many parallel sessions open across unrelated repositories.

package/docs/concept.zh.md

@@ -2,51 +2,51 @@
 
 [English](concept.md) | [한국어](concept.ko.md) | [简体中文](concept.zh.md) | [日本語](concept.ja.md) | [Español](concept.es.md)
 
-## Summary
+## 摘要
 
-`gctree` 是一个小而明确的全局上下文层，面向 AI 编码工具。它把长期上下文放在单一仓库之外的 markdown 文档中，可以按 gc-branch 切换、检索和维护，也可以限制某个 gc-branch 只在真正相关的仓库中生效。
+`gctree` 是一层面向 AI 编码工具的轻量级全局上下文层。它把长期上下文放在单个仓库之外、以显式 markdown 文档的形式保存，让你可以在不同 gc-branch 之间切换，并且把每条 gc-branch 的影响范围限制在真正相关的仓库里。
 
 ## `gctree` 是什么
 
-`gctree` 是一个用于管理可复用全局上下文的轻量 CLI。
-它面向那些需要在多个仓库、多个会话和多种工具之间持续复用长期上下文的个人与团队。
+`gctree` 是一个用来管理可复用全局上下文的 CLI。
+它面向的是这样一种需求：长期上下文需要在多个仓库、多个会话、多个工具之间持续存在，但又不能变成一个看不见、摸不着的“隐式记忆黑盒”。
 
-与其把长期知识交给隐藏记忆，或者散落在多个提示文件中，`gctree` 更像是为这些知识提供了一个清晰、稳定、基于文件的归档位置。
+与其把重要知识分散在提示词文件、仓库内笔记和临时指令里，不如让 `gctree` 给这些知识一个稳定、可追踪、由文件承载的家。
 
 ## 它解决什么问题
 
-很多 AI 编码工作流最初都从下面这些方式开始：
+很多 AI 编码环境一开始都很简单：
 
 - 一个 `AGENTS.md`
 - 一个 `CLAUDE.md`
-- 仓库里的本地提示文件
-- 一组临时复制到提示词里的笔记
+- 一个仓库内提示词文件
+- 几段需要时再复制进提示词里的笔记
 
-一开始这样可以工作，但随着项目变复杂，往往会出现这些需求：
+一开始这样完全够用。但一旦进入真实工作场景，这套做法很快就会吃力。
 
-- 希望按产品或客户隔离上下文
-- 希望把上下文放在单个仓库之外长期维护
-- 希望多种工具复用同一套长期文档
-- 希望用一致的方式快速找到正确的上下文
-- 希望以更安全的方式持续更新长期上下文
-- 同一个用户会同时在多个仓库和多个会话中并行工作
+- 不同产品需要不同的上下文
+- 客户项目之间必须隔离
+- 可复用的指导信息应该放在单个仓库之外
+- 多个工具应该能读取同一份 source of truth
+- 长期上下文应该通过安全、可审阅的流程来演进
+- 同一个人可能同时在多个仓库里跑很多个会话
 
-`gctree` 解决的正是这一层问题。
+`gctree` 存在的目的，就是把这一层问题单独而清晰地解决掉。
 
-## 范围边界
+## 边界在哪里
 
-`gctree` 有意不做以下事情：
+`gctree` 有意不去做下面这些事：
 
-- request-to-commit 交付编排器
-- 隐式记忆系统
+- 从需求一路编排到 commit 的交付系统
+- 隐藏式记忆系统
 - 浏览器协作运行时
 - 通用知识库产品
 
-它专注于可复用的全局上下文分支，以及显式的更新流程。
+它只专注一件事：管理可复用的全局上下文分支，以及这些分支上的显式更新。
 
-## 文件结构
+## 文件模型
 
-一个典型的 home 目录大致如下：
+一个典型的主目录结构大致如下：
 
 ```text
 ~/.gctree/
@@ -60,22 +60,22 @@
       docs/
 ```
 
-- `HEAD` 记录 fallback 的激活 gc-branch。
-- `settings.json` 保存 provider 模式、实际用于启动 onboarding 的 provider，以及首选工作流语言。
-- `branch-repo-map.json` 保存每个 gc-branch 的 include/exclude 仓库规则。
-- `branch.json` 保存轻量级 gc-branch 元数据。
-- `index.md` 是工具读取时的紧凑入口。
-- `docs/` 存放 source-of-truth markdown 文档。
+- `HEAD` 记录默认激活的 gc-branch。
+- `settings.json` 保存 provider 模式、运行时启动时选用的 onboarding provider，以及偏好的工作流语言。
+- `branch-repo-map.json` 保存每条 gc-branch 对哪些仓库包含或排除。
+- `branch.json` 保存轻量级的 gc-branch 元数据。
+- `index.md` 是工具首先进入的紧凑入口。
+- `docs/` 用来保存 source-of-truth markdown 文档。
 
-## 仓库范围行为
+## 面向仓库的行为
 
-某个 gc-branch 不一定需要作用于所有仓库。
-如果 branch `A` 只适用于 `B`、`C`、`D`，就可以把这个关系写进 `branch-repo-map.json`。
+gc-branch 不需要在所有地方都生效。
+如果 branch `A` 只和仓库 `B`、`C`、`D` 有关，`gctree` 就可以把这件事记录到 `branch-repo-map.json` 里。
 
-这样一来，当 `F` 仓库里运行 `gctree resolve` 时，可以选择：
+这样一来，当你在另一个仓库 `F` 里执行 `gctree resolve` 时，它可以这样处理：
 
-- 这次先继续
-- 以后这个仓库总是使用这个 gc-branch
-- 在这个仓库里忽略这个 gc-branch
+- 只这一次继续
+- 以后在 `F` 里始终使用这条 gc-branch
+- 在 `F` 里忽略这条 gc-branch
 
-这让 `gctree` 更适合同时开很多会话、在多个不相关仓库里并行工作的 heavy 用户。
+对于那些同时在多个互不相关仓库里开很多并行会话的重度用户来说，这会让 gc-tree 安全得多，也更实用。

package/docs/local-development.es.md

@@ -2,76 +2,76 @@
 
 [English](local-development.md) | [한국어](local-development.ko.md) | [简体中文](local-development.zh.md) | [日本語](local-development.ja.md) | [Español](local-development.es.md)
 
-## Summary
+## Resumen
 
-El desarrollo local sigue un flujo estándar de Node.js 20+: instala dependencias, construye la CLI, ejecútala localmente y verifica con la suite de tests existente antes de enviar cambios.
+El desarrollo local sigue un flujo estándar de Node.js 20+: instalar dependencias, compilar la CLI, ejecutarla localmente y verificar los cambios con la suite de tests existente antes de enviarlos.
 
 ## Requisitos previos
 
 - Node.js 20+
 - npm
-- binarios locales de `codex` o `claude` si quieres validar manualmente el arranque del provider
+- binarios locales de `codex` y / o `claude` si quieres probar manualmente el arranque de providers
 
-## Configuración
+## Preparación
 
 ```bash
 npm install
 npm run build
 ```
 
-## Ejecutar la CLI localmente
+## Ejecuta la CLI en local
 
-### Opción 1: ejecutar directamente la entrada construida
+### Opción 1: ejecutar directamente la entrada ya compilada
 
 ```bash
 node dist/src/cli.js status
 ```
 
-### Opción 2: enlazar la CLI a tu shell
+### Opción 2: enlazar la CLI en tu shell
 
 ```bash
 npm link
 gctree status
 ```
 
-Si cambias el código TypeScript, vuelve a construir antes de probar de nuevo la CLI.
+Si cambias archivos TypeScript, vuelve a compilar antes de probar otra vez la CLI.
 
 ## Verificación
 
-Antes de enviar cambios, ejecuta:
+Ejecuta esto antes de abrir un pull request:
 
 ```bash
 npm run build
 npm test
 ```
 
-## Tests de alcance por repositorio
+## Tests de repo scope
 
-La suite actual verifica:
+La suite de tests cubre ahora:
 
 - persistencia del modo de provider (`claude-code`, `codex`, `both`)
-- persistencia del idioma preferido y refuerzo fuerte del idioma en el launch prompt
-- selección de gc-branch según el repositorio
-- interacciones include/exclude durante `resolve`
-- actualización del branch repo map
-- límites del flujo guiado de onboarding/update
+- persistencia del idioma preferido y aplicación estricta del idioma en los launch prompts
+- selección de gc-branch con conciencia de repositorio
+- decisiones interactivas de include / exclude durante `resolve`
+- actualizaciones del branch repo map
+- límites del flujo guiado de onboarding / update
 
-## Verificación manual E2E del provider
+## Comprobaciones manuales E2E de providers
 
-Los tests automáticos desactivan el provider launch para validar el launch plan sin abrir sesiones reales de Codex o Claude Code.
-Si quieres comprobar el camino real de arranque, usa un directorio temporal y ejecuta:
+Los tests automatizados desactivan el lanzamiento de providers para poder verificar los launch plans sin abrir sesiones reales de Codex o Claude Code.
+Si quieres probar la ruta real de lanzamiento, ejecuta uno de estos comandos dentro de un directorio desechable:
 
 ```bash
 gctree init --provider codex
 gctree init --provider claude-code
 ```
 
-Si todo está bien, el provider se abrirá de verdad y recibirá inmediatamente `$gc-onboard` o `/gc-onboard`.
+Deberías ver que el provider se abre y recibe inmediatamente `$gc-onboard` o `/gc-onboard`.
 
 ## Estructura del proyecto
 
-- `src/` — CLI, almacenamiento de contexto, selección de provider, mapeo de alcance por repositorio, flujos guiados de onboarding/update y lógica de scaffolding
-- `tests/` — tests de CLI y comportamiento
-- `skills/` — skills de flujo de trabajo agnósticos a la herramienta
-- `scaffolds/` — plantillas bootstrap específicas del host
-- `docs/` — documentación de concept, principles, usage y development
+- `src/` — CLI, almacenamiento de contexto, selección de provider, mapeo de repo scope, flujos guiados de onboarding / update y lógica de scaffolding
+- `tests/` — tests de CLI y de comportamiento
+- `skills/` — habilidades de flujo de trabajo independientes de la herramienta
+- `scaffolds/` — plantillas de arranque específicas por host
+- `docs/` — documentación de concepto, principios, uso y desarrollo

package/docs/local-development.ja.md

@@ -1,16 +1,16 @@
-# ローカル実行方法
+# ローカル開発
 
 [English](local-development.md) | [한국어](local-development.ko.md) | [简体中文](local-development.zh.md) | [日本語](local-development.ja.md) | [Español](local-development.es.md)
 
-## Summary
+## 要約
 
-ローカル開発は標準的な Node.js 20+ ワークフローです。依存関係を入れ、CLI をビルドし、ローカルで実行し、提出前に既存テストで検証します。
+ローカル開発は、一般的な Node.js 20+ の流れに沿っています。依存関係を入れ、CLI をビルドし、ローカルで実行し、変更を送る前に既存のテストスイートで検証します。
 
 ## 前提条件
 
 - Node.js 20+
 - npm
-- provider 起動を手動で確認したい場合は、ローカルの `codex` または `claude` バイナリ
+- provider 起動を自分で試したい場合はローカルの `codex` と / または `claude` バイナリ
 
 ## セットアップ
 
@@ -19,7 +19,7 @@ npm install
 npm run build
 ```
 
-## ローカルで CLI を実行する
+## CLI をローカルで実行する
 
 ### 方法 1: ビルド済みエントリを直接実行する
 
@@ -34,44 +34,44 @@ npm link
 gctree status
 ```
 
-TypeScript ソースを変更した場合は、再度 CLI を試す前にビルドし直してください。
+TypeScript のソースを変更したら、CLI を再テストする前にもう一度ビルドしてください。
 
 ## 検証
 
-変更を提出する前に次を実行してください。
+プルリクエストを開く前に、次を実行します。
 
 ```bash
 npm run build
 npm test
 ```
 
-## リポジトリ範囲テスト
+## repo-scope テスト
 
-現在のテストスイートでは次を検証しています。
+現在のテストスイートでは、次をカバーしています。
 
-- provider モード（`claude-code`、`codex`、`both`）の保存
-- 優先言語の保存と launch prompt での強い言語固定
-- リポジトリに応じた gc-branch 選択
-- `resolve` 中の include/exclude インタラクション
+- provider モードの保存（`claude-code`、`codex`、`both`）
+- 優先言語の保存と launch prompt での強い言語維持
+- リポジトリを意識した gc-branch 選択
+- `resolve` 実行中の include / exclude の対話
 - branch repo map の更新
-- ガイド付きオンボーディング/更新フローの境界条件
+- ガイド付きオンボーディング / 更新の境界条件
 
-## 手動 provider E2E 検証
+## provider の手動 E2E チェック
 
-自動テストでは provider launch を無効にしているため、Codex や Claude Code の実セッションは開かず、launch plan だけを確認します。
-実際の起動経路を手元で確認したい場合は、使い捨てディレクトリで次を実行してください。
+自動テストでは、Codex や Claude Code のセッションを実際に開かなくても launch plan を検証できるよう、provider 起動を無効化しています。
+本物の launch path を試したい場合は、使い捨てディレクトリで次のどちらかを実行してください。
 
 ```bash
 gctree init --provider codex
 gctree init --provider claude-code
 ```
 
-正常なら provider が実際に起動し、すぐに `$gc-onboard` または `/gc-onboard` が渡されます。
+正しく動けば、provider が起動し、すぐに `$gc-onboard` または `/gc-onboard` を受け取るはずです。
 
 ## プロジェクト構成
 
-- `src/` — CLI、コンテキスト保存、provider 選択、リポジトリ範囲マッピング、ガイド付きオンボーディング/更新フロー、scaffolding ロジック
-- `tests/` — CLI と挙動のテスト
+- `src/` — CLI、本体のコンテキスト保存、provider 選択、repo-scope マッピング、ガイド付きオンボーディング / 更新フロー、scaffolding ロジック
+- `tests/` — CLI と振る舞いのテスト
 - `skills/` — ツール非依存のワークフロースキル
-- `scaffolds/` — ホスト別 bootstrap テンプレート
-- `docs/` — concept、principles、usage、development ドキュメント
+- `scaffolds/` — ホスト別のブートストラップテンプレート
+- `docs/` — 概念、原則、使い方、開発ドキュメント

package/docs/local-development.ko.md

@@ -1,16 +1,16 @@
-# 로컬 실행방법
+# 로컬 개발
 
 [English](local-development.md) | [한국어](local-development.ko.md) | [简体中文](local-development.zh.md) | [日本語](local-development.ja.md) | [Español](local-development.es.md)
 
-## Summary
+## 요약
 
-로컬 개발은 일반적인 Node.js 20+ 워크플로를 따릅니다. 의존성을 설치하고, CLI를 빌드한 뒤, 로컬에서 실행하고, 제출 전에 기존 테스트로 검증하면 됩니다.
+로컬 개발은 일반적인 Node.js 20+ 흐름을 따릅니다. 의존성을 설치하고, CLI를 빌드하고, 로컬에서 실행해 보고, 변경을 보내기 전에 기존 테스트 스위트로 검증하면 됩니다.
 
-## 준비사항
+## 준비물
 
 - Node.js 20+
 - npm
-- provider 런치를 수동으로 점검하려면 로컬 `codex` 또는 `claude` 바이너리
+- provider 실행을 직접 확인해보고 싶다면 로컬 `codex` 및 / 또는 `claude` 바이너리
 
 ## 설정
 
@@ -19,7 +19,7 @@ npm install
 npm run build
 ```
 
-## 로컬에서 CLI 실행
+## 로컬에서 CLI 실행하기
 
 ### 방법 1: 빌드된 엔트리를 직접 실행
 
@@ -27,51 +27,51 @@ npm run build
 node dist/src/cli.js status
 ```
 
-### 방법 2: 셸에 CLI를 링크
+### 방법 2: CLI를 셸에 링크해서 사용
 
 ```bash
 npm link
 gctree status
 ```
 
-TypeScript 소스를 수정했다면 다시 테스트하기 전에 재빌드하세요.
+TypeScript 소스를 수정했다면 CLI를 다시 테스트하기 전에 한 번 더 빌드하세요.
 
 ## 검증
 
-변경을 제출하기 전에 다음을 실행하세요.
+PR을 열기 전에 아래 명령을 실행하세요.
 
 ```bash
 npm run build
 npm test
 ```
 
-## 레포 범위 관련 테스트
+## repo-scope 테스트
 
-현재 테스트 스위트는 다음을 검증합니다.
+현재 테스트 스위트는 다음을 커버합니다.
 
-- provider 모드(`claude-code`, `codex`, `both`) 저장
-- 선호 언어 저장과 launch prompt에서의 강한 언어 고정
-- 레포에 따른 gc-branch 선택
-- `resolve` 중 include/exclude 인터랙션
-- branch repo map 갱신
-- 가이드형 온보딩/업데이트 경계 조건
+- provider 모드 저장 (`claude-code`, `codex`, `both`)
+- 선호 언어 저장과 launch prompt에서의 강한 언어 유지
+- 레포 인식 gc-branch 선택
+- `resolve` 중 include / exclude 인터랙션
+- branch repo map 업데이트
+- 가이드형 온보딩 / 업데이트 경계
 
-## 수동 provider E2E 점검
+## provider 수동 E2E 확인
 
-자동 테스트는 Codex/Claude Code 세션을 실제로 열지 않도록 provider launch를 비활성화한 상태에서 launch plan만 검증합니다.
-실제 런치 경로를 직접 확인하고 싶다면 임시 디렉터리에서 다음처럼 실행하면 됩니다.
+자동화 테스트는 Codex나 Claude Code 세션을 실제로 열지 않고도 launch plan을 검증할 수 있도록 provider 실행을 비활성화해 둡니다.
+실제 launch 경로를 직접 확인해보고 싶다면, 임시 디렉터리에서 아래 중 하나를 실행해 보세요.
 
 ```bash
 gctree init --provider codex
 gctree init --provider claude-code
 ```
 
-정상이라면 provider가 실제로 열리고, 바로 `$gc-onboard` 또는 `/gc-onboard` 명령이 주입되어야 합니다.
+정상이라면 provider가 열리고 바로 `$gc-onboard` 또는 `/gc-onboard`를 받게 됩니다.
 
 ## 프로젝트 구조
 
-- `src/` — CLI, 컨텍스트 저장소, provider 선택, 레포 범위 매핑, 가이드형 온보딩/업데이트 흐름, 스캐폴딩 로직
+- `src/` — CLI, 컨텍스트 저장소, provider 선택, repo-scope 매핑, 가이드형 온보딩 / 업데이트 흐름, 스캐폴딩 로직
 - `tests/` — CLI 및 동작 테스트
-- `skills/` — 도구 독립형 워크플로 스킬
-- `scaffolds/` — 호스트별 bootstrap 템플릿
-- `docs/` — concept, principles, usage, development 문서
+- `skills/` — 도구 비종속 워크플로 스킬
+- `scaffolds/` — 호스트별 부트스트랩 템플릿
+- `docs/` — 개념, 원칙, 사용법, 개발 문서

package/docs/local-development.md

@@ -4,7 +4,7 @@
 
 ## Summary
 
-Local development follows a standard Node.js 20+ workflow: install dependencies, build the CLI, run it locally, and verify with the existing test suite before you send changes.
+Local development follows a standard Node.js 20+ workflow: install dependencies, build the CLI, run it locally, and verify your changes with the existing test suite before you send them out.
 
 ## Prerequisites
 
@@ -47,7 +47,7 @@ npm test
 
 ## Repo-scope tests
 
-The test suite now covers:
+The test suite currently covers:
 
 - provider mode persistence (`claude-code`, `codex`, `both`)
 - preferred language persistence and strong language enforcement in launch prompts
@@ -58,7 +58,7 @@ The test suite now covers:
 
 ## Manual provider E2E checks
 
-Automated tests disable provider launch so they can verify launch plans without opening Codex or Claude Code sessions.
+Automated tests disable provider launch so they can verify launch plans without opening real Codex or Claude Code sessions.
 If you want to dogfood the real launch path, run one of these in a throwaway directory:
 
 ```bash