@handsupmin/gc-tree 0.1.4 → 0.2.0

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.md CHANGED
@@ -19,208 +19,223 @@ Manage multiple contexts like Git branches.
19
19
 
20
20
  </div>
21
21
 
22
- Built for developers whose real work spans **multiple repos, products, clients, and workflows**.
23
-
24
- `gc-tree` gives AI coding tools a reusable context layer **above the repo level**. Keep long-lived context across sessions, scope it to the right repos, and let `gc-tree` stay out of the way when the current repo is unrelated.
25
-
26
22
  ---
27
23
 
28
- ## Why gc-tree?
24
+ ## The problem
29
25
 
30
- If you use AI agents seriously, repo-local context stops being enough.
26
+ You use Claude Code or Codex every day. But your real work spans multiple repos, products, and clients and your AI tools only know about the current file.
31
27
 
32
- Once your work spans multiple repos and workstreams, the usual setup starts to break:
28
+ So you end up doing this every session:
33
29
 
34
- - durable context gets stuffed into prompts
35
- - unrelated context leaks into the wrong repo
36
- - every new session needs the same onboarding again
37
- - client or product knowledge lives in hidden chat history
38
- - switching workstreams means manually switching mental context too
30
+ - Re-explain which repos belong together
31
+ - Paste the same architecture doc into the prompt again
32
+ - Remind the agent about conventions it already "knew" last week
33
+ - Manually strip context that's irrelevant to the current repo
39
34
 
40
- `gc-tree` is for the people who already use Codex, Claude Code, and other AI coding tools heavily — and want context management to stop being another manual workflow.
35
+ That's not an AI problem. It's a **context management problem**.
41
36
 
42
37
  ---
43
38
 
44
- ## What you get
39
+ ## What gc-tree does
45
40
 
46
- - **Multiple durable contexts**
47
- Keep separate context lanes for different products, clients, or workstreams.
41
+ `gc-tree` sits **above the repo level**. It stores durable context in structured markdown files and lets your AI tools pull only what's relevant — before each session, automatically.
48
42
 
49
- - **Repo-scoped relevance**
50
- Map each context to the repos where it actually belongs.
43
+ ```bash
44
+ gctree resolve --query "auth token rotation policy"
45
+ ```
51
46
 
52
- - **Smart scope guard**
53
- If you enter a repo that is not mapped yet, `gc-tree` can ask whether to continue once, always use this context here, or ignore it here.
47
+ ```json
48
+ {
49
+ "gc_branch": "main",
50
+ "matches": [
51
+ {
52
+ "title": "Auth & Session Conventions",
53
+ "score": 4,
54
+ "summary": "JWT rotation on every request, refresh tokens stored in httpOnly cookies, 15-min access token TTL",
55
+ "excerpt": "## Auth Flow\nAccess token: 15-min TTL, rotated on every authenticated request..."
56
+ }
57
+ ]
58
+ }
59
+ ```
54
60
 
55
- - **Guided onboarding and updates**
56
- Use Codex, Claude Code, or both to onboard and maintain context over time.
61
+ Your AI tool gets the right context. Not the whole knowledge base — just the relevant slice.
57
62
 
58
- - **Summary-first markdown knowledge**
59
- Store reusable context in files, not hidden memory, and let tools read the short version first.
63
+ **In practice: only ~4% of your total context is injected per query.** The other 96% stays on disk, out of the token window, until it's actually needed.
60
64
 
61
65
  ---
62
66
 
63
- ## Install & quick start
64
-
65
- ```bash
66
- npm install -g @handsupmin/gc-tree
67
- gctree init
68
- ```
67
+ ## Who this is for
69
68
 
70
- That is enough to get started.
71
- After that, keep working the way you already do — `gc-tree` adds a reusable global context lane around your normal workflow.
69
+ You'll get the most out of `gc-tree` if you:
72
70
 
73
- - **CLI command:** `gctree`
74
- - **Requirements:** Node.js 20+
71
+ - Work across **multiple repos** (monorepo teams, platform + client repos, backend + frontend stacks)
72
+ - Switch between **multiple products or clients** in the same week
73
+ - Find yourself **re-explaining the same context** at the start of every AI session
74
+ - Want AI tools to understand your **conventions, architecture, and domain knowledge** — not just the current file
75
75
 
76
- For source-based development, see [docs/local-development.md](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.md).
76
+ If you only ever work in one repo and one product, you probably don't need this. `CLAUDE.md` or `.cursorrules` is enough.
77
77
 
78
78
  ---
79
79
 
80
- ## Common moves
80
+ ## Why not just use CLAUDE.md or cursor rules?
81
81
 
82
- ### Create a new context when a workstream deserves its own lane
82
+ `CLAUDE.md` is great for one repo.
83
83
 
84
- ```bash
85
- gctree checkout -b client-b
86
- gctree onboard
87
- ```
84
+ The moment you have multiple repos, clients, or workstreams:
88
85
 
89
- When a client, product, migration, or initiative deserves its own durable lane, give it its own gc-branch.
86
+ | | `CLAUDE.md` / cursor rules | `gc-tree` |
87
+ |---|---|---|
88
+ | Scope | One repo | Multiple repos, one context |
89
+ | Persistence | Per-repo file | Stored outside repos, reused across sessions |
90
+ | Switching contexts | Manual file edits | `gctree checkout client-b` |
91
+ | Relevance filtering | Everything or nothing | Only injects matching docs (~4% of total) |
92
+ | Onboarding | Hand-written | Guided by your AI tool |
93
+ | Works with Codex | ✅ | ✅ |
94
+ | Works with Claude Code | ✅ | ✅ |
90
95
 
91
- ### Update durable context later
96
+ ---
92
97
 
93
- ```bash
94
- gctree update-global-context
95
- ```
98
+ ## Validated performance
96
99
 
97
- Refresh the active gc-branch as the work evolves.
100
+ Tested against real internal documentation (4 Notion exports, Korean + English mixed queries):
98
101
 
99
- Short aliases:
102
+ | Metric | Result |
103
+ |---|---|
104
+ | Recall — relevant queries find the right doc | **100%** (16/16) |
105
+ | Precision — irrelevant queries return empty | **80%** (4/5) |
106
+ | F1 score | **88.9%** |
107
+ | Tokens injected per query vs. total context | **~4%** |
108
+ | Works with mixed Korean + English queries | ✅ |
100
109
 
101
- ```bash
102
- gctree update-gc
103
- gctree ugc
104
- ```
110
+ ---
105
111
 
106
- ### Resolve context when you need it
112
+ ## Works with Claude Code and Codex — both verified
107
113
 
108
114
  ```bash
109
- gctree resolve --query "auth token rotation"
115
+ gctree scaffold --host claude-code # installs CLAUDE.md snippet + /gc-onboard, /gc-update-global-context
116
+ gctree scaffold --host codex # installs AGENTS.md snippet + $gc-onboard, $gc-update-global-context
117
+ gctree scaffold --host both # both at once
110
118
  ```
111
119
 
112
- Pull relevant context back into the current moment when you want it.
113
-
114
- ---
120
+ Both providers use the same underlying context store. Onboard once, use from either tool.
115
121
 
116
- ## Why it feels natural
122
+ **Claude Code** uses `/gc-resolve-context`, `/gc-onboard`, `/gc-update-global-context` slash commands.
117
123
 
118
- **Keep multiple contexts like Git branches without babysitting them like Git branches.**
124
+ **Codex** uses `$gc-resolve-context`, `$gc-onboard`, `$gc-update-global-context` skills. Verified with `codex exec`:
119
125
 
120
- You can create separate contexts for:
126
+ ```
127
+ gctree status → gc_branch: main, doc_count: 2
128
+ gctree resolve --query 'NestJS DTO plainToInstance'
129
+ → matched "Backend Coding Conventions" (score: 3)
130
+ → DTO: class-transformer plainToInstance, class-validator required
131
+ → Error handling: HttpException-based custom exceptions, no raw Error throws
132
+ ```
121
133
 
122
- - a client
123
- - a product line
124
- - a platform team
125
- - a shared backend + frontend stack
126
- - a temporary initiative or migration
134
+ ---
127
135
 
128
- Then switch between them with familiar branch-like commands:
136
+ ## Install & quick start
129
137
 
130
138
  ```bash
131
- gctree checkout -b client-b
132
- gctree checkout main
139
+ npm install -g @handsupmin/gc-tree
140
+ gctree init
133
141
  ```
134
142
 
135
- But unlike Git, you do **not** have to manually manage that switch all the time.
143
+ `gctree init` walks you through:
144
+ 1. Choose provider: `claude-code`, `codex`, or `both`
145
+ 2. Scaffold the integration files into your current repo
146
+ 3. Run guided onboarding for the `main` gc-branch
136
147
 
137
- If the repo you are in is outside the scope of the current context, `gc-tree` can detect that and treat the context as irrelevant instead of leaking it into the wrong session.
148
+ After that, your AI tool will know to call `gctree resolve` before planning or implementing.
138
149
 
139
- That means you can keep multiple long-lived contexts around without dragging unrelated context into every tool session.
150
+ - **CLI:** `gctree`
151
+ - **Requires:** Node.js 20+
140
152
 
141
153
  ---
142
154
 
143
- ## A realistic workflow
144
-
145
- You work across:
155
+ ## Common moves
146
156
 
147
- - one shared platform repo
148
- - two client repos
149
- - one internal tooling repo
157
+ ### Separate contexts for separate workstreams
150
158
 
151
- Without `gc-tree`, every AI session has to be re-taught:
159
+ ```bash
160
+ gctree checkout -b client-b
161
+ gctree onboard
162
+ ```
152
163
 
153
- - which client this is
154
- - which repos belong together
155
- - which workflows matter here
156
- - which context is irrelevant right now
164
+ Each gc-branch is a fully independent context lane. Switch between them like Git branches.
157
165
 
158
- With `gc-tree`, you can keep separate contexts for each lane, reuse them across sessions, and let repo-scope rules prevent irrelevant context from showing up where it should not.
166
+ ### Pull relevant context on demand
159
167
 
160
- This is the real job to be done:
168
+ ```bash
169
+ gctree resolve --query "billing retry policy"
170
+ ```
161
171
 
162
- > not “store more prompt text,”
163
- > but **manage the right context at the right level of work**.
172
+ Returns only the matching docs — title, summary, and excerpt. Your tool reads the full doc only if the summary isn't enough.
164
173
 
165
- ---
174
+ ### Keep context current
166
175
 
167
- ## Core concepts
176
+ ```bash
177
+ gctree update-global-context # or: gctree update-gc / gctree ugc
178
+ ```
168
179
 
169
- - **gc-branch**
170
- A durable context lane for one product, client, workstream, or domain.
180
+ Guided update flow — your AI tool asks what changed and writes the new context back to the gc-branch.
171
181
 
172
- - **repo scope**
173
- Rules that decide which repos a context should apply to.
182
+ ### Scope a context to specific repos
174
183
 
175
- - **provider-guided flow**
176
- Use your preferred AI coding tool to onboard and update context instead of hand-authoring JSON.
184
+ ```bash
185
+ gctree set-repo-scope --branch client-b --include # include current repo
186
+ gctree set-repo-scope --branch client-b --exclude # exclude current repo
187
+ ```
177
188
 
178
- - **context tree**
179
- Under the hood, `gc-tree` organizes context as branch-aware, file-backed knowledge.
180
- The “tree” is the implementation model; the user-facing benefit is reusable context beyond the project.
189
+ `gc-tree` won't inject a context into repos where it doesn't belong.
181
190
 
182
191
  ---
183
192
 
184
- ## Provider-facing commands inside the runtime
185
-
186
- After scaffolding, the visible commands are:
193
+ ## How context is stored
187
194
 
188
- - **Codex:** `$gc-onboard`, `$gc-update-global-context`
189
- - **Claude Code:** `/gc-onboard`, `/gc-update-global-context`
195
+ ```
196
+ ~/.gctree/
197
+ branches/
198
+ main/
199
+ index.md ← compact index, ≤2000 chars, loaded first
200
+ docs/
201
+ auth.md ← full doc, read only when needed
202
+ architecture.md
203
+ client-b/
204
+ index.md
205
+ docs/
206
+ ...
207
+ branch-repo-map.json ← which repos belong to which gc-branch
208
+ settings.json ← preferred provider, language
209
+ ```
190
210
 
191
- Those commands should always mention the current active gc-branch before gathering or updating durable context, and they should keep using the saved workflow language unless the user explicitly asks to switch.
211
+ Context lives outside your repos no `.gitignore` rules needed, no accidental commits, reusable across every project that uses the same gc-branch.
192
212
 
193
213
  ---
194
214
 
195
- ## Core commands at a glance
196
-
197
- | Goal | Command |
198
- | ------------------------------------------------- | ------------------------------------------------------------------ |
199
- | Initialize gc-tree and choose a provider | `gctree init` |
200
- | Confirm the active gc-branch | `gctree status` |
201
- | Search the active context | `gctree resolve --query "..."` |
202
- | Show repo-scope rules | `gctree repo-map` |
203
- | Explicitly include/exclude a repo for a gc-branch | `gctree set-repo-scope --branch <name> --include` / `--exclude` |
204
- | Create or switch gc-branches | `gctree checkout <branch>` / `gctree checkout -b <branch>` |
205
- | Guided onboarding for an empty gc-branch | `gctree onboard` |
206
- | Guided durable update for the active gc-branch | `gctree update-global-context` / `gctree update-gc` / `gctree ugc` |
207
- | Reset a gc-branch before re-onboarding | `gctree reset-gc-branch --branch <name> --yes` |
208
- | Scaffold another environment manually | `gctree scaffold --host codex --target /path/to/repo` |
215
+ ## Core commands
216
+
217
+ | Goal | Command |
218
+ |---|---|
219
+ | Initialize gc-tree and choose a provider | `gctree init` |
220
+ | Confirm the active gc-branch | `gctree status` |
221
+ | Search the active context | `gctree resolve --query "..."` |
222
+ | Create or switch gc-branches | `gctree checkout <branch>` / `gctree checkout -b <branch>` |
223
+ | List all gc-branches | `gctree branches` |
224
+ | Guided onboarding for an empty gc-branch | `gctree onboard` |
225
+ | Guided durable update for the active gc-branch | `gctree update-global-context` / `gctree ugc` |
226
+ | Show repo-scope rules | `gctree repo-map` |
227
+ | Include/exclude current repo for a gc-branch | `gctree set-repo-scope --branch <name> --include` / `--exclude` |
228
+ | Reset a gc-branch before re-onboarding | `gctree reset-gc-branch --branch <name> --yes` |
229
+ | Scaffold a new environment | `gctree scaffold --host codex --target /path/to/repo` |
209
230
 
210
231
  ---
211
232
 
212
233
  ## Documentation
213
234
 
214
- Detailed docs live in the [`docs/`](https://github.com/handsupmin/gc-tree/tree/main/docs) directory.
215
-
216
235
  - **Concept** — [`docs/concept.md`](https://github.com/handsupmin/gc-tree/blob/main/docs/concept.md)
217
- Learn what `gctree` is, which problem it solves, and what belongs in the global-context layer.
218
236
  - **Principles** — [`docs/principles.md`](https://github.com/handsupmin/gc-tree/blob/main/docs/principles.md)
219
- Read the rules behind gc-branches, repo scope, slim indexes, summary-first docs, and guided updates.
220
237
  - **Usage** — [`docs/usage.md`](https://github.com/handsupmin/gc-tree/blob/main/docs/usage.md)
221
- See the standard CLI flow, provider-facing commands, repo-scope behavior, and integration patterns.
222
238
  - **Local development** — [`docs/local-development.md`](https://github.com/handsupmin/gc-tree/blob/main/docs/local-development.md)
223
- Learn how to run the CLI locally and verify changes before contributing.
224
239
 
225
240
  ---
226
241