@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.es.md +139 -70
- package/README.ja.md +143 -74
- package/README.ko.md +141 -72
- package/README.md +152 -83
- package/README.zh.md +142 -74
- package/docs/concept.es.md +37 -37
- package/docs/concept.ja.md +43 -43
- package/docs/concept.ko.md +41 -41
- package/docs/concept.md +15 -15
- package/docs/concept.zh.md +37 -37
- package/docs/local-development.es.md +25 -25
- package/docs/local-development.ja.md +22 -22
- package/docs/local-development.ko.md +25 -25
- package/docs/local-development.md +3 -3
- package/docs/local-development.zh.md +23 -23
- package/docs/principles.es.md +27 -26
- package/docs/principles.ja.md +28 -27
- package/docs/principles.ko.md +29 -28
- package/docs/principles.md +4 -4
- package/docs/principles.zh.md +28 -27
- package/docs/usage.es.md +32 -30
- package/docs/usage.ja.md +45 -43
- package/docs/usage.ko.md +41 -39
- package/docs/usage.md +2 -2
- package/docs/usage.zh.md +46 -44
- package/package.json +1 -1
package/README.zh.md
CHANGED
|
@@ -1,107 +1,101 @@
|
|
|
1
1
|
# gc-tree
|
|
2
2
|
|
|
3
|
-
|
|
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
|
+
[](https://www.npmjs.com/package/@handsupmin/gc-tree)
|
|
13
|
+
[](https://www.npmjs.com/package/@handsupmin/gc-tree)
|
|
14
|
+
[](https://github.com/handsupmin/gc-tree/stargazers)
|
|
15
|
+
[](https://github.com/handsupmin/gc-tree/blob/main/LICENSE)
|
|
16
|
+
[](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
|
-
|
|
10
|
-
它为长期上下文提供了一个可复用、基于文件、支持分支的明确归宿,而且可以自然接入现有工作流。
|
|
22
|
+
这是为那些日常工作横跨多个仓库、产品、客户和工作流的开发者准备的。
|
|
11
23
|
|
|
12
|
-
|
|
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
|
-
-
|
|
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
|
-
|
|
34
|
+
- 长期上下文被不断塞进提示词里
|
|
35
|
+
- 不相关的上下文泄漏到别的仓库
|
|
36
|
+
- 每开一个新会话都要重新讲一遍背景
|
|
37
|
+
- 客户或产品知识只藏在聊天记录里
|
|
38
|
+
- 每次切换工作流,都得靠人脑手动切换上下文
|
|
36
39
|
|
|
37
|
-
|
|
38
|
-
npm install -g @handsupmin/gc-tree
|
|
39
|
-
```
|
|
40
|
+
`gc-tree` 是给那些已经深度使用 Codex、Claude Code 等 AI 编码工具、但不想再手动维护上下文的人准备的。
|
|
40
41
|
|
|
41
|
-
|
|
42
|
+
---
|
|
42
43
|
|
|
43
|
-
|
|
44
|
-
npx @handsupmin/gc-tree init
|
|
45
|
-
```
|
|
44
|
+
## 它能直接带来什么
|
|
46
45
|
|
|
47
|
-
-
|
|
48
|
-
|
|
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
|
-
|
|
52
|
+
- **更聪明的范围保护**
|
|
53
|
+
当你进入一个尚未映射的仓库时,可以选择只继续这一次、以后都在这里启用,或者在这里忽略它。
|
|
55
54
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
```
|
|
55
|
+
- **带引导的 onboarding 与更新**
|
|
56
|
+
可以用 Codex、Claude Code,或者两者一起,把上下文建立起来并持续维护。
|
|
59
57
|
|
|
60
|
-
|
|
58
|
+
- **summary-first 的 markdown 知识结构**
|
|
59
|
+
知识留在文件里,而不是藏在隐式记忆里;工具可以先读摘要,再决定要不要展开全文。
|
|
61
60
|
|
|
62
|
-
|
|
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
|
-
|
|
63
|
+
## 安装与快速开始
|
|
72
64
|
|
|
73
65
|
```bash
|
|
74
|
-
|
|
66
|
+
npm install -g @handsupmin/gc-tree
|
|
67
|
+
gctree init
|
|
75
68
|
```
|
|
76
69
|
|
|
77
|
-
|
|
70
|
+
这样就可以开工了。
|
|
71
|
+
之后照你原来的开发方式继续就行,`gc-tree` 只是把一层可复用的全局上下文加在你现有流程外面。
|
|
78
72
|
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
3. 在这个仓库里忽略这个 gc-branch
|
|
73
|
+
- **CLI 命令:** `gctree`
|
|
74
|
+
- **要求:** Node.js 20+
|
|
82
75
|
|
|
83
|
-
|
|
76
|
+
如果你想从源码开发,请看 [docs/local-development.zh.md](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.zh.md)。
|
|
84
77
|
|
|
85
|
-
|
|
78
|
+
---
|
|
86
79
|
|
|
87
|
-
|
|
88
|
-
gctree checkout -b client-b
|
|
89
|
-
```
|
|
80
|
+
## 常用操作
|
|
90
81
|
|
|
91
|
-
|
|
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
|
-
|
|
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
|
-
|
|
106
|
+
### 需要的时候再把上下文取出来
|
|
113
107
|
|
|
114
|
-
|
|
115
|
-
|
|
108
|
+
```bash
|
|
109
|
+
gctree resolve --query "auth token rotation"
|
|
110
|
+
```
|
|
116
111
|
|
|
117
|
-
|
|
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
|
|
131
|
+
gctree checkout -b client-b
|
|
132
|
+
gctree checkout main
|
|
121
133
|
```
|
|
122
134
|
|
|
123
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
|
200
|
+
| 搜索当前激活的上下文 | `gctree resolve --query "..."` |
|
|
139
201
|
| 查看仓库范围规则 | `gctree repo-map` |
|
|
140
|
-
| 为 gc-branch
|
|
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)。
|
package/docs/concept.es.md
CHANGED
|
@@ -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
|
-
##
|
|
5
|
+
## Resumen
|
|
6
6
|
|
|
7
|
-
`gctree` es una capa de contexto global
|
|
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
|
|
12
|
-
Está pensada para
|
|
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
|
|
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
|
|
18
|
+
Muchos entornos de programación con IA empiezan de forma bastante simple:
|
|
19
19
|
|
|
20
|
-
- un
|
|
21
|
-
- un
|
|
22
|
-
- un archivo de
|
|
23
|
-
-
|
|
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
|
|
25
|
+
Eso funciona durante un tiempo. Pero cuando empiezan a aparecer necesidades reales, la misma configuración empieza a romperse:
|
|
26
26
|
|
|
27
|
-
-
|
|
28
|
-
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
-
|
|
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`
|
|
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`
|
|
38
|
+
`gctree` no pretende ser:
|
|
39
39
|
|
|
40
|
-
- un orquestador
|
|
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
|
|
43
|
+
- un producto de base de conocimiento de propósito general
|
|
44
44
|
|
|
45
|
-
Se
|
|
45
|
+
Se concentra en una sola tarea: gestionar ramas de contexto global reutilizable y sus actualizaciones explícitas.
|
|
46
46
|
|
|
47
|
-
##
|
|
47
|
+
## Modelo de archivos
|
|
48
48
|
|
|
49
|
-
Un directorio
|
|
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`
|
|
64
|
-
- `settings.json` guarda el modo de provider, el provider
|
|
65
|
-
- `branch-repo-map.json` guarda
|
|
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
|
|
68
|
-
- `docs/`
|
|
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
|
|
70
|
+
## Comportamiento con conciencia de repositorio
|
|
71
71
|
|
|
72
|
-
Un gc-branch no tiene por qué aplicarse
|
|
73
|
-
Si la rama `A` solo es relevante para `B`, `C` y `D`,
|
|
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
|
-
|
|
75
|
+
Cuando `gctree resolve` se ejecuta desde otro repositorio, por ejemplo `F`, puede:
|
|
76
76
|
|
|
77
|
-
- continuar solo
|
|
78
|
-
- usar siempre
|
|
79
|
-
-
|
|
77
|
+
- continuar solo una vez
|
|
78
|
+
- usar siempre ese gc-branch en `F`
|
|
79
|
+
- ignorar ese gc-branch en `F`
|
|
80
80
|
|
|
81
|
-
Eso
|
|
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í.
|
package/docs/concept.ja.md
CHANGED
|
@@ -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
|
-
##
|
|
5
|
+
## 要約
|
|
6
6
|
|
|
7
|
-
`gctree` は AI
|
|
7
|
+
`gctree` は AI コーディングツール向けの軽量なグローバルコンテキストレイヤーです。単一リポジトリの外側に長期コンテキストを明示的な markdown 文書として置き、gc-branch を切り替えながら文脈を使い分けられるようにし、各 gc-branch が本当に関係あるリポジトリにだけ影響するよう制御できます。
|
|
8
8
|
|
|
9
|
-
## `gctree`
|
|
9
|
+
## `gctree` とは何か
|
|
10
10
|
|
|
11
|
-
`gctree`
|
|
12
|
-
|
|
11
|
+
`gctree` は再利用できるグローバルコンテキストを管理するための CLI です。
|
|
12
|
+
複数のリポジトリ、複数のセッション、複数のツールをまたいでも長期コンテキストが生き残るようにしつつ、それをブラックボックスな隠れメモリにはしない、という前提で作られています。
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
大事な知識がプロンプトファイル、リポジトリ内メモ、場当たり的な指示に散らばる代わりに、`gctree` はその知識に安定したファイルベースの置き場所を与えます。
|
|
15
15
|
|
|
16
|
-
##
|
|
16
|
+
## 何の問題を解決するのか
|
|
17
17
|
|
|
18
|
-
多くの AI
|
|
18
|
+
多くの AI コーディング環境は、最初はこんな形で始まります。
|
|
19
19
|
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
-
|
|
20
|
+
- `AGENTS.md` が 1 つ
|
|
21
|
+
- `CLAUDE.md` が 1 つ
|
|
22
|
+
- リポジトリ内の短いプロンプトファイルが 1 つ
|
|
23
|
+
- 必要なときだけプロンプトに貼り付けるメモが少し
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
しばらくはそれで回ります。けれど実務が乗ってくると、同じやり方はすぐ苦しくなります。
|
|
26
26
|
|
|
27
|
-
-
|
|
28
|
-
-
|
|
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
|
-
-
|
|
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`
|
|
64
|
-
- `settings.json`
|
|
65
|
-
- `branch-repo-map.json`
|
|
66
|
-
- `branch.json`
|
|
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
|
-
|
|
73
|
-
たとえば branch `A` が `B`、`C`、`D`
|
|
72
|
+
gc-branch はどこでも有効である必要はありません。
|
|
73
|
+
たとえば branch `A` が repo `B`、`C`、`D` にしか関係しないなら、その事実を `branch-repo-map.json` に記録できます。
|
|
74
74
|
|
|
75
|
-
|
|
75
|
+
その状態で別の repo `F` から `gctree resolve` を実行した場合、`gctree` は次のように扱えます。
|
|
76
76
|
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
77
|
+
- 今回だけ続ける
|
|
78
|
+
- 今後も `F` ではその gc-branch を使う
|
|
79
|
+
- `F` ではその gc-branch を無視する
|
|
80
80
|
|
|
81
|
-
|
|
81
|
+
これによって、無関係なリポジトリをまたいで多くの並行セッションを開いているヘビーユーザーでも、gc-tree をかなり安全に使えます。
|