@handsupmin/gc-tree 0.1.3 → 0.1.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.zh.md CHANGED
@@ -1,107 +1,101 @@
1
1
  # gc-tree
2
2
 
3
- 面向 AI 编码工具的分支化全局上下文层。
3
+ <div align="center">
4
+
5
+ <img src="./logo.png" alt="gc-tree logo" width="260" />
6
+
7
+ ### 不止于项目内部的全局上下文。
8
+
9
+ 在你现有的 AI 工具之上,再加一层可复用、能长期积累的上下文。
10
+ 像管理 Git 分支一样管理多条上下文线索。
11
+
12
+ [![npm version](https://img.shields.io/npm/v/%40handsupmin%2Fgc-tree)](https://www.npmjs.com/package/@handsupmin/gc-tree)
13
+ [![npm downloads](https://img.shields.io/npm/dm/%40handsupmin%2Fgc-tree)](https://www.npmjs.com/package/@handsupmin/gc-tree)
14
+ [![GitHub stars](https://img.shields.io/github/stars/handsupmin/gc-tree)](https://github.com/handsupmin/gc-tree/stargazers)
15
+ [![License: MIT](https://img.shields.io/badge/license-MIT-yellow.svg)](https://github.com/handsupmin/gc-tree/blob/main/LICENSE)
16
+ [![Node.js](https://img.shields.io/badge/node-%3E%3D20-brightgreen)](https://nodejs.org)
4
17
 
5
18
  [English](https://github.com/handsupmin/gc-tree/blob/main/README.md) | [한국어](https://github.com/handsupmin/gc-tree/blob/main/README.ko.md) | [简体中文](https://github.com/handsupmin/gc-tree/blob/main/README.zh.md) | [日本語](https://github.com/handsupmin/gc-tree/blob/main/README.ja.md) | [Español](https://github.com/handsupmin/gc-tree/blob/main/README.es.md)
6
19
 
7
- ## 介绍
20
+ </div>
8
21
 
9
- `gctree` 是一个面向 AI 编码工具的轻量级 **Global Context Tree**。
10
- 它为长期上下文提供了一个可复用、基于文件、支持分支的明确归宿,而且可以自然接入现有工作流。
22
+ 这是为那些日常工作横跨多个仓库、产品、客户和工作流的开发者准备的。
11
23
 
12
- 当单个 `AGENTS.md`、`CLAUDE.md` 或一段提示词已经不够时,`gctree` 可以帮助你:
24
+ `gc-tree` AI 编码工具补上了一层 **仓库之上的可复用上下文层**。该长期保留的上下文可以留下来,只在相关仓库里生效,不相关的时候就安静退场。
13
25
 
14
- - 按产品、客户或工作流隔离上下文
15
- - 用 markdown 文档保存 source of truth,而不是依赖隐藏记忆
16
- - 通过精简索引和 summary-first 文档更快定位当前上下文
17
- - 通过偏好的 LLM CLI 完成 onboarding 与长期更新
18
- - 让某个 gc-branch 只作用于真正相关的仓库
26
+ ---
19
27
 
20
- ## 简要特性
28
+ ## 为什么是 gc-tree?
21
29
 
22
- - **Provider 驱动的 onboarding**
23
- `gctree init` 会先询问你想使用哪种 provider 模式(`claude-code`、`codex` 或 `both`),再询问响应语言,并保存这些选择,然后给当前环境安装对应的命令表面,并为默认 `main` gc-branch 启动引导式 onboarding。
24
- - **带仓库范围的 gc-branch**
25
- 你可以通过 `~/.gctree/branch-repo-map.json` 把某个 gc-branch 绑定到指定仓库集合,比如让 A 只作用于 B/C/D,而在 F 中忽略。
26
- - **交互式范围保护**
27
- 如果 `gctree resolve` 发现当前仓库还没有映射到这个 gc-branch,它可以询问是仅本次继续、以后总是使用,还是在这个仓库里忽略它。
28
- - **Summary-first 文档结构**
29
- 工具可以先读取简短摘要,只有在需要时才展开完整文档。
30
- - **引导式长期更新**
31
- 不需要手写 JSON 文件,也可以通过同样的 provider 流程更新全局上下文。
30
+ 只要你开始认真把 AI 代理用进日常开发,repo-local context 很快就不够用了。
32
31
 
33
- ## 安装与快速开始
32
+ 一旦工作同时分布在多个仓库和多个工作流上,常见问题就会一起出现:
34
33
 
35
- ### 通过 npm 安装
34
+ - 长期上下文被不断塞进提示词里
35
+ - 不相关的上下文泄漏到别的仓库
36
+ - 每开一个新会话都要重新讲一遍背景
37
+ - 客户或产品知识只藏在聊天记录里
38
+ - 每次切换工作流,都得靠人脑手动切换上下文
36
39
 
37
- ```bash
38
- npm install -g @handsupmin/gc-tree
39
- ```
40
+ `gc-tree` 是给那些已经深度使用 Codex、Claude Code 等 AI 编码工具、但不想再手动维护上下文的人准备的。
40
41
 
41
- 如果你只想临时运行一次,也可以:
42
+ ---
42
43
 
43
- ```bash
44
- npx @handsupmin/gc-tree init
45
- ```
44
+ ## 它能直接带来什么
46
45
 
47
- - **包名:** `@handsupmin/gc-tree`
48
- - **CLI 命令:** `gctree`
49
- - **要求:** Node.js 20+
50
- 如果要从源码开发,请查看 [docs/local-development.md](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.md)。
46
+ - **多条可长期维护的上下文**
47
+ 你可以按产品、客户或工作流,分别维护自己的上下文线。
51
48
 
52
- ### 快速开始
49
+ - **按仓库控制相关性**
50
+ 可以明确指定某条上下文只该作用于哪些仓库。
53
51
 
54
- #### 1) 初始化 gc-tree
52
+ - **更聪明的范围保护**
53
+ 当你进入一个尚未映射的仓库时,可以选择只继续这一次、以后都在这里启用,或者在这里忽略它。
55
54
 
56
- ```bash
57
- gctree init
58
- ```
55
+ - **带引导的 onboarding 与更新**
56
+ 可以用 Codex、Claude Code,或者两者一起,把上下文建立起来并持续维护。
59
57
 
60
- 这个命令会:
58
+ - **summary-first 的 markdown 知识结构**
59
+ 知识留在文件里,而不是藏在隐式记忆里;工具可以先读摘要,再决定要不要展开全文。
61
60
 
62
- - 创建 `~/.gctree`
63
- - 创建默认 `main` gc-branch
64
- - 让你选择 provider 模式(`claude-code`、`codex` 或 `both`)
65
- - 如果你选择 `both`,再选择这次 onboarding 要由哪个 provider 启动
66
- - 让你选择语言(`English`、`Korean`,或手动输入语言)
67
- - 把 provider 模式、实际 onboarding provider 和语言保存到 `~/.gctree/settings.json`
68
- - 为当前环境安装对应的命令表面
69
- - 当 `main` 仍为空时,为当前 gc-branch 启动引导式 onboarding
61
+ ---
70
62
 
71
- #### 2) 解析当前上下文
63
+ ## 安装与快速开始
72
64
 
73
65
  ```bash
74
- gctree resolve --query "auth token rotation"
66
+ npm install -g @handsupmin/gc-tree
67
+ gctree init
75
68
  ```
76
69
 
77
- 如果当前仓库不在这个 gc-branch 的映射范围内,`gctree` 可以让你选择:
70
+ 这样就可以开工了。
71
+ 之后照你原来的开发方式继续就行,`gc-tree` 只是把一层可复用的全局上下文加在你现有流程外面。
78
72
 
79
- 1. 这次先继续
80
- 2. 以后这个仓库总是使用这个 gc-branch
81
- 3. 在这个仓库里忽略这个 gc-branch
73
+ - **CLI 命令:** `gctree`
74
+ - **要求:** Node.js 20+
82
75
 
83
- 如果选择 2 或 3,`~/.gctree/branch-repo-map.json` 会被更新。
76
+ 如果你想从源码开发,请看 [docs/local-development.zh.md](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.zh.md)。
84
77
 
85
- #### 3) 需要独立上下文时创建新的 gc-branch
78
+ ---
86
79
 
87
- ```bash
88
- gctree checkout -b client-b
89
- ```
80
+ ## 常用操作
90
81
 
91
- `checkout -b` 会创建一个**新的空 gc-branch**,不会复制已有分支里的文档。
92
-
93
- #### 4) 为一个空的 gc-branch 执行 onboarding
82
+ ### 当一个工作流值得拥有自己的上下文时,先开一条新分支
94
83
 
95
84
  ```bash
85
+ gctree checkout -b client-b
96
86
  gctree onboard
97
87
  ```
98
88
 
99
- #### 5) 后续执行长期上下文更新
89
+ 不管是客户项目、产品线、迁移工作,还是某个阶段性的专项,只要值得单独维护背景,就给它单开一个 gc-branch。
90
+
91
+ ### 之后再把长期上下文补进去
100
92
 
101
93
  ```bash
102
94
  gctree update-global-context
103
95
  ```
104
96
 
97
+ 随着工作推进,把真正值得长期保留的信息补到当前激活的 gc-branch 里。
98
+
105
99
  简短别名:
106
100
 
107
101
  ```bash
@@ -109,41 +103,111 @@ gctree update-gc
109
103
  gctree ugc
110
104
  ```
111
105
 
112
- 如果实际工作后发现某个仓库确实属于当前 gc-branch,更自然的流程是:
106
+ ### 需要的时候再把上下文取出来
113
107
 
114
- 1. 先把这个仓库加入 branch repo map
115
- 2. 再用 `gctree update-global-context` 补充这个仓库是什么、为什么重要等长期上下文
108
+ ```bash
109
+ gctree resolve --query "auth token rotation"
110
+ ```
116
111
 
117
- #### 6) 重新 onboarding 前先重置 gc-branch
112
+ 等你真的需要某段背景时,再把它拉回当前时刻。
113
+
114
+ ---
115
+
116
+ ## 为什么它用起来很顺手
117
+
118
+ **你可以像管理 Git 分支一样保留多条上下文,但不用像管理 Git 分支那样时时盯着。**
119
+
120
+ 你可以把上下文拆成这些维度:
121
+
122
+ - 客户
123
+ - 产品线
124
+ - 平台团队
125
+ - 一起演进的后端 + 前端技术栈
126
+ - 临时专项或迁移项目
127
+
128
+ 切换方式也很熟悉:
118
129
 
119
130
  ```bash
120
- gctree reset-gc-branch --branch client-b --yes
131
+ gctree checkout -b client-b
132
+ gctree checkout main
121
133
  ```
122
134
 
123
- ### 运行时可见的 provider 命令
135
+ 但和 Git 不一样的是,这种切换不需要你一直手动维护。
136
+
137
+ 如果你当前所在的仓库根本不在这条上下文的作用范围内,`gc-tree` 可以把它判断为“此处无关”,而不是硬塞进当前会话里。
138
+
139
+ 这样一来,你可以长期保留多条上下文,却不用把所有背景都拖进每一次工具会话里。
140
+
141
+ ---
142
+
143
+ ## 一个更贴近现实的工作流
144
+
145
+ 假设你平时同时在这些地方工作:
146
+
147
+ - 一个共享平台仓库
148
+ - 两个客户项目仓库
149
+ - 一个内部工具仓库
150
+
151
+ 没有 `gc-tree` 的话,每次开新的 AI 会话都得重新交代:
152
+
153
+ - 现在讨论的是哪个客户
154
+ - 哪些仓库其实是一组
155
+ - 当前最重要的工作流是什么
156
+ - 哪些上下文放进来反而会干扰
124
157
 
125
- scaffold 之后,在运行时可见的命令是:
158
+ 有了 `gc-tree`,你就可以按工作线维护不同上下文,在会话之间复用,并用 repo scope 规则挡住那些不该混进来的背景。
159
+
160
+ 它真正解决的不是“多存一点提示词”,而是:
161
+
162
+ > **在对的工作层级上,管理对的上下文。**
163
+
164
+ ---
165
+
166
+ ## 核心概念
167
+
168
+ - **gc-branch**
169
+ 面向某个产品、客户、工作流或领域的一条长期上下文线。
170
+
171
+ - **repo scope**
172
+ 决定这条上下文应该在哪些仓库里生效的规则。
173
+
174
+ - **provider-guided flow**
175
+ 不手写 JSON,而是借助你熟悉的 AI 编码工具完成 onboarding 和更新。
176
+
177
+ - **context tree**
178
+ 在实现上,`gc-tree` 把上下文组织成一棵按分支感知、由文件承载的知识树。
179
+ 对用户来说,核心价值就是:项目之外也能复用的上下文。
180
+
181
+ ---
182
+
183
+ ## 运行时里可见的 provider 命令
184
+
185
+ scaffold 完成后,运行时可见的命令是:
126
186
 
127
187
  - **Codex:** `$gc-onboard`, `$gc-update-global-context`
128
188
  - **Claude Code:** `/gc-onboard`, `/gc-update-global-context`
129
189
 
130
- 这些命令在开始收集或更新长期上下文之前,都应该先明确说明当前激活的是哪个 gc-branch,并且除非用户明确要求切换,否则要始终使用保存下来的语言。
190
+ 这些命令在开始收集或更新长期上下文之前,都应该先说明当前激活的是哪个 gc-branch,并且除非用户明确要求切换,否则应持续使用已经保存的语言。
191
+
192
+ ---
131
193
 
132
- ### 核心命令速览
194
+ ## 核心命令速览
133
195
 
134
196
  | 目标 | 命令 |
135
197
  | --- | --- |
136
198
  | 初始化 gc-tree 并选择 provider | `gctree init` |
137
199
  | 确认当前 gc-branch | `gctree status` |
138
- | 搜索当前上下文 | `gctree resolve --query "..."` |
200
+ | 搜索当前激活的上下文 | `gctree resolve --query "..."` |
139
201
  | 查看仓库范围规则 | `gctree repo-map` |
140
- | 为 gc-branch 显式设置仓库包含/排除 | `gctree set-repo-scope --branch <name> --include` / `--exclude` |
202
+ | 为 gc-branch 显式设置仓库包含 / 排除 | `gctree set-repo-scope --branch <name> --include` / `--exclude` |
141
203
  | 创建或切换 gc-branch | `gctree checkout <branch>` / `gctree checkout -b <branch>` |
142
204
  | 为一个空的 gc-branch 执行 onboarding | `gctree onboard` |
143
205
  | 为当前 gc-branch 执行长期更新 | `gctree update-global-context` / `gctree update-gc` / `gctree ugc` |
144
206
  | 重新 onboarding 前重置 gc-branch | `gctree reset-gc-branch --branch <name> --yes` |
145
207
  | 手动为其他环境安装 scaffold | `gctree scaffold --host codex --target /path/to/repo` |
146
208
 
209
+ ---
210
+
147
211
  ## 文档
148
212
 
149
213
  详细文档位于 [`docs/`](https://github.com/handsupmin/gc-tree/tree/main/docs) 目录下。
@@ -157,10 +221,14 @@ scaffold 之后,在运行时可见的命令是:
157
221
  - **本地运行方法** — [`docs/local-development.zh.md`](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.zh.md)
158
222
  说明依赖安装、本地运行 CLI 与提交前验证方式。
159
223
 
224
+ ---
225
+
160
226
  ## 贡献
161
227
 
162
228
  欢迎贡献。开发流程与 PR 检查清单位于英文文档 [CONTRIBUTING.md](https://github.com/handsupmin/gc-tree/blob/main/CONTRIBUTING.md)。
163
229
 
230
+ ---
231
+
164
232
  ## 许可证
165
233
 
166
234
  MIT。详见 [`LICENSE`](https://github.com/handsupmin/gc-tree/blob/main/LICENSE)。
@@ -2,51 +2,51 @@
2
2
 
3
3
  [English](concept.md) | [한국어](concept.ko.md) | [简体中文](concept.zh.md) | [日本語](concept.ja.md) | [Español](concept.es.md)
4
4
 
5
- ## Summary
5
+ ## Resumen
6
6
 
7
- `gctree` es una capa de contexto global pequeña y clara para herramientas de programación con IA. Mantiene el contexto duradero en documentos markdown fuera de un único repositorio, permite cambiarlo y consultarlo por gc-branch, y además puede limitar cada gc-branch a los repositorios donde realmente aplica.
7
+ `gctree` es una capa ligera de contexto global para herramientas de programación con IA. Mantiene el contexto duradero en documentos markdown explícitos fuera de cualquier repositorio individual, permite cambiar entre gc-branches y puede limitar cada gc-branch a los repositorios donde realmente tiene sentido.
8
8
 
9
9
  ## Qué es `gctree`
10
10
 
11
- `gctree` es una CLI ligera para gestionar contexto global reutilizable.
12
- Está pensada para personas y equipos que necesitan conservar el mismo contexto duradero entre varios repositorios, sesiones y herramientas.
11
+ `gctree` es una CLI para gestionar contexto global reutilizable.
12
+ Está pensada para equipos y personas que quieren que el contexto de largo recorrido sobreviva entre repositorios, sesiones y herramientas, sin convertirlo en una memoria oculta imposible de inspeccionar.
13
13
 
14
- En lugar de dejar ese conocimiento repartido entre archivos de prompts o depender de memoria oculta, `gctree` le da un lugar claro, estable y basado en archivos.
14
+ En lugar de repartir el conocimiento importante entre archivos de prompt, notas locales al repo e instrucciones improvisadas, `gctree` le da a ese conocimiento un hogar estable, visible y respaldado por archivos.
15
15
 
16
16
  ## Qué problema resuelve
17
17
 
18
- Muchos entornos de programación con IA empiezan con una de estas opciones:
18
+ Muchos entornos de programación con IA empiezan de forma bastante simple:
19
19
 
20
- - un solo `AGENTS.md`
21
- - un solo `CLAUDE.md`
22
- - un archivo de prompts dentro del repositorio
23
- - un conjunto de notas copiadas manualmente en los prompts
20
+ - un `AGENTS.md`
21
+ - un `CLAUDE.md`
22
+ - un archivo de prompt dentro del repo
23
+ - unas pocas notas que se copian al prompt cuando hacen falta
24
24
 
25
- Eso funciona al principio, pero con el tiempo aparecen necesidades como estas:
25
+ Eso funciona durante un tiempo. Pero cuando empiezan a aparecer necesidades reales, la misma configuración empieza a romperse:
26
26
 
27
- - separar el contexto por producto o cliente
28
- - mantener contexto fuera de un único repositorio
29
- - reutilizar la misma documentación duradera desde varias herramientas
30
- - encontrar el contexto correcto de forma rápida y consistente
31
- - actualizar el contexto duradero de una forma más segura
32
- - trabajar en paralelo en muchos repositorios y sesiones a la vez
27
+ - cada producto necesita un contexto distinto
28
+ - el trabajo para clientes debe mantenerse aislado
29
+ - la guía reutilizable debería vivir fuera de un único repositorio
30
+ - varias herramientas deberían poder leer la misma source of truth
31
+ - el contexto duradero debería evolucionar con un flujo seguro y revisable
32
+ - una misma persona puede tener muchas sesiones abiertas en muchos repos a la vez
33
33
 
34
- `gctree` se ocupa precisamente de esa capa.
34
+ `gctree` existe para resolver precisamente esa capa del problema, y hacerlo de forma limpia.
35
35
 
36
36
  ## Límite de alcance
37
37
 
38
- `gctree` intencionalmente no es:
38
+ `gctree` no pretende ser:
39
39
 
40
- - un orquestador de entrega request-to-commit
40
+ - un orquestador integral que lleve una petición hasta el commit
41
41
  - un sistema de memoria oculta
42
42
  - un runtime de colaboración en navegador
43
- - un producto generalista de base de conocimiento
43
+ - un producto de base de conocimiento de propósito general
44
44
 
45
- Se centra en ramas reutilizables de contexto global y en flujos de actualización explícitos.
45
+ Se concentra en una sola tarea: gestionar ramas de contexto global reutilizable y sus actualizaciones explícitas.
46
46
 
47
- ## Estructura de archivos
47
+ ## Modelo de archivos
48
48
 
49
- Un directorio home típico se ve así:
49
+ Un directorio personal típico queda así:
50
50
 
51
51
  ```text
52
52
  ~/.gctree/
@@ -60,22 +60,22 @@ Un directorio home típico se ve así:
60
60
  docs/
61
61
  ```
62
62
 
63
- - `HEAD` indica el gc-branch activo de fallback.
64
- - `settings.json` guarda el modo de provider, el provider real usado para iniciar el onboarding y el idioma preferido del flujo.
65
- - `branch-repo-map.json` guarda las reglas include/exclude por gc-branch.
63
+ - `HEAD` sigue el gc-branch activo por defecto.
64
+ - `settings.json` guarda el modo de provider, el provider elegido para lanzar el onboarding en runtime y el idioma preferido del flujo.
65
+ - `branch-repo-map.json` guarda qué repositorios están incluidos o excluidos para cada gc-branch.
66
66
  - `branch.json` guarda metadatos ligeros del gc-branch.
67
- - `index.md` es el punto de entrada compacto para las herramientas.
68
- - `docs/` guarda los documentos markdown source-of-truth.
67
+ - `index.md` es el punto de entrada compacto para herramientas y personas.
68
+ - `docs/` contiene los documentos markdown que actúan como source of truth.
69
69
 
70
- ## Comportamiento con alcance por repositorio
70
+ ## Comportamiento con conciencia de repositorio
71
71
 
72
- Un gc-branch no tiene por qué aplicarse a todos los repositorios.
73
- Si la rama `A` solo es relevante para `B`, `C` y `D`, eso puede registrarse en `branch-repo-map.json`.
72
+ Un gc-branch no tiene por qué aplicarse en todas partes.
73
+ Si la rama `A` solo es relevante para los repositorios `B`, `C` y `D`, `gctree` puede dejarlo registrado en `branch-repo-map.json`.
74
74
 
75
- Entonces, si ejecutas `gctree resolve` desde `F`, puedes elegir entre:
75
+ Cuando `gctree resolve` se ejecuta desde otro repositorio, por ejemplo `F`, puede:
76
76
 
77
- - continuar solo esta vez
78
- - usar siempre esa rama en ese repo
79
- - ignorarla en ese repo
77
+ - continuar solo una vez
78
+ - usar siempre ese gc-branch en `F`
79
+ - ignorar ese gc-branch en `F`
80
80
 
81
- Eso vuelve a `gctree` mucho más seguro para usuarios intensivos que mantienen muchas sesiones paralelas abiertas sobre repositorios no relacionados.
81
+ Eso hace que gc-tree sea mucho más seguro para quienes mantienen muchas sesiones paralelas abiertas en repositorios que no tienen relación entre sí.
@@ -1,52 +1,52 @@
1
- # コンセプト
1
+ # 概念
2
2
 
3
3
  [English](concept.md) | [한국어](concept.ko.md) | [简体中文](concept.zh.md) | [日本語](concept.ja.md) | [Español](concept.es.md)
4
4
 
5
- ## Summary
5
+ ## 要約
6
6
 
7
- `gctree` は AI コーディングツール向けの、小さく明確なグローバルコンテキストレイヤーです。長期コンテキストを単一リポジトリの外にある markdown 文書として管理し、gc-branch 単位で切り替え・参照・維持でき、さらに実際に関係するリポジトリだけに適用範囲を絞れます。
7
+ `gctree` は AI コーディングツール向けの軽量なグローバルコンテキストレイヤーです。単一リポジトリの外側に長期コンテキストを明示的な markdown 文書として置き、gc-branch を切り替えながら文脈を使い分けられるようにし、各 gc-branch が本当に関係あるリポジトリにだけ影響するよう制御できます。
8
8
 
9
- ## `gctree` とは
9
+ ## `gctree` とは何か
10
10
 
11
- `gctree` は再利用可能なグローバルコンテキストを管理するための軽量 CLI です。
12
- 複数のリポジトリ、セッション、ツールをまたいでも同じ長期コンテキストを使い続けたい個人やチームのために設計されています。
11
+ `gctree` は再利用できるグローバルコンテキストを管理するための CLI です。
12
+ 複数のリポジトリ、複数のセッション、複数のツールをまたいでも長期コンテキストが生き残るようにしつつ、それをブラックボックスな隠れメモリにはしない、という前提で作られています。
13
13
 
14
- 長期知識を隠れたメモリに任せたり、複数のプロンプトファイルへ散らしたりする代わりに、`gctree` はその知識に明確で安定したファイルベースの置き場所を与えます。
14
+ 大事な知識がプロンプトファイル、リポジトリ内メモ、場当たり的な指示に散らばる代わりに、`gctree` はその知識に安定したファイルベースの置き場所を与えます。
15
15
 
16
- ## 解決する課題
16
+ ## 何の問題を解決するのか
17
17
 
18
- 多くの AI コーディング環境は、次のいずれかから始まります。
18
+ 多くの AI コーディング環境は、最初はこんな形で始まります。
19
19
 
20
- - 1 つの `AGENTS.md`
21
- - 1 つの `CLAUDE.md`
22
- - リポジトリ内のローカルなプロンプトファイル
23
- - プロンプトに都度貼り付けるメモ
20
+ - `AGENTS.md` が 1 つ
21
+ - `CLAUDE.md` が 1 つ
22
+ - リポジトリ内の短いプロンプトファイルが 1 つ
23
+ - 必要なときだけプロンプトに貼り付けるメモが少し
24
24
 
25
- 最初はそれで十分でも、やがて次のような要件が出てきます。
25
+ しばらくはそれで回ります。けれど実務が乗ってくると、同じやり方はすぐ苦しくなります。
26
26
 
27
- - プロダクトやクライアントごとにコンテキストを分けたい
28
- - 1 つのリポジトリの外にコンテキストを保ちたい
29
- - 複数ツールが同じ長期文書を再利用できるようにしたい
30
- - 必要なコンテキストを一貫した方法で素早く見つけたい
31
- - 長期コンテキストをより安全に更新したい
32
- - 同じユーザーが複数のリポジトリ・複数のセッションで並行作業する
27
+ - プロダクトごとに必要なコンテキストが違う
28
+ - クライアント案件は互いに分離しておく必要がある
29
+ - 再利用したいガイダンスは単一リポジトリの外に置きたい
30
+ - 複数ツールが同じ source of truth を読めるべき
31
+ - 長期コンテキストは安全でレビュー可能な流れで育てたい
32
+ - 1 人のユーザーが同時に複数リポジトリで複数セッションを動かすことがある
33
33
 
34
- `gctree` は、まさにその層を扱います。
34
+ `gctree` は、まさにそのレイヤーをきれいに扱うためのものです。
35
35
 
36
- ## スコープ境界
36
+ ## スコープの境界
37
37
 
38
- `gctree` が意図的に担当しないものは次の通りです。
38
+ `gctree` は意図的に、次のものではありません。
39
39
 
40
- - request-to-commit 型のデリバリーオーケストレータ
41
- - 隠れたメモリシステム
42
- - ブラウザ協業ランタイム
40
+ - リクエストからコミットまでを一気通貫で回す実行オーケストレータ
41
+ - 隠れメモリの仕組み
42
+ - ブラウザ型のコラボレーションランタイム
43
43
  - 汎用ナレッジベース製品
44
44
 
45
- `gctree` は、再利用可能なグローバルコンテキストブランチと、明示的な更新フローに集中します。
45
+ `gctree` が集中する仕事は 1 つです。再利用できるグローバルコンテキストブランチと、その明示的な更新を管理することです。
46
46
 
47
- ## ファイル構成
47
+ ## ファイルモデル
48
48
 
49
- 典型的なホームディレクトリ構成は次の通りです。
49
+ 典型的なホームディレクトリ配下の構成はこうなります。
50
50
 
51
51
  ```text
52
52
  ~/.gctree/
@@ -60,22 +60,22 @@
60
60
  docs/
61
61
  ```
62
62
 
63
- - `HEAD` fallback のアクティブ gc-branch を指します。
64
- - `settings.json` provider モード、実際のオンボーディング起動 provider、優先ワークフロー言語を保持します。
65
- - `branch-repo-map.json` gc-branch ごとの include/exclude リポジトリ規則を保存します。
66
- - `branch.json` は軽量な gc-branch メタデータを保存します。
67
- - `index.md` はツール向けの小さな入口です。
68
- - `docs/` には source-of-truth の markdown 文書を保存します。
63
+ - `HEAD` はデフォルトでアクティブになる gc-branch を追跡します。
64
+ - `settings.json` には provider モード、ランタイム起動に使うオンボーディング provider、優先するワークフロー言語が入ります。
65
+ - `branch-repo-map.json` には各 gc-branch ごとのリポジトリの include / exclude 情報が入ります。
66
+ - `branch.json` には軽量な gc-branch メタデータが入ります。
67
+ - `index.md` はツールが最初に読むコンパクトな入口です。
68
+ - `docs/` には source-of-truth の markdown 文書が入ります。
69
69
 
70
- ## リポジトリ範囲の振る舞い
70
+ ## リポジトリを意識した振る舞い
71
71
 
72
- ある gc-branch がすべてのリポジトリに適用される必要はありません。
73
- たとえば branch `A` が `B`、`C`、`D` にだけ関係するなら、その事実を `branch-repo-map.json` に記録できます。
72
+ gc-branch はどこでも有効である必要はありません。
73
+ たとえば branch `A` が repo `B`、`C`、`D` にしか関係しないなら、その事実を `branch-repo-map.json` に記録できます。
74
74
 
75
- その状態で `F` リポジトリから `gctree resolve` を実行すると、次を選べます。
75
+ その状態で別の repo `F` から `gctree resolve` を実行した場合、`gctree` は次のように扱えます。
76
76
 
77
- - 今回だけ使う
78
- - 今後もこのリポジトリで使う
79
- - このリポジトリでは無視する
77
+ - 今回だけ続ける
78
+ - 今後も `F` ではその gc-branch を使う
79
+ - `F` ではその gc-branch を無視する
80
80
 
81
- これにより、多数のセッションを開いて複数の無関係なリポジトリで並行作業する heavy ユーザーにも、より安全に使えるようになります。
81
+ これによって、無関係なリポジトリをまたいで多くの並行セッションを開いているヘビーユーザーでも、gc-tree をかなり安全に使えます。