|
1 | 1 | # code-context-graph |
2 | 2 |
|
3 | | -코드베이스를 Tree-sitter로 파싱하여 지식 그래프를 구축하는 로컬 코드 분석 도구. |
| 3 | +A local code analysis tool that parses codebases with Tree-sitter and builds a knowledge graph. |
4 | 4 |
|
5 | | -## MCP 서버 |
| 5 | +## MCP Server |
6 | 6 |
|
7 | | -`.mcp.json`에 등록된 ccg MCP 서버가 35개 도구를 제공합니다: |
| 7 | +The ccg MCP server registered in `.mcp.json` provides 35 tools: |
8 | 8 |
|
9 | 9 | - `parse_project`, `build_or_update_graph`, `run_postprocess` |
10 | 10 | - `get_postprocess_policy`, `reset_postprocess_policy` |
|
18 | 18 | - `upload_file`, `upload_files`, `list_namespaces`, `list_files`, `delete_file`, `delete_namespace` |
19 | 19 | - `list_workspaces`, `delete_workspace` (deprecated aliases) |
20 | 20 |
|
21 | | -HTTP 모드 (`--transport streamable-http`)에서는 `/health` 및 `/webhook` 엔드포인트도 제공합니다. |
22 | | -Webhook은 `--allow-repo` 플래그로 허용 리포지토리를 설정하면 활성화됩니다. |
23 | | -레포별 브랜치 필터링: `--allow-repo "org/api:main,develop"` (glob 패턴, 미지정 시 main/master 기본). |
24 | | -GitHub (`X-Hub-Signature-256`) 및 Gitea (`X-Gitea-Signature`, `X-Gitea-Event`) 호환. |
25 | | -Push 이벤트 수신 → 자동 clone/pull → 그래프 빌드 → DB 저장 파이프라인. |
26 | | -Graceful shutdown: SIGINT/SIGTERM 시 진행 중인 clone/build에 context cancel 전파. |
| 21 | +In HTTP mode (`--transport streamable-http`), it also provides `/health` and `/webhook` endpoints. |
| 22 | +Webhooks are enabled when allowed repositories are configured with the `--allow-repo` flag. |
| 23 | +Per-repository branch filtering: `--allow-repo "org/api:main,develop"` (glob patterns; defaults to main/master when omitted). |
| 24 | +Compatible with GitHub (`X-Hub-Signature-256`) and Gitea (`X-Gitea-Signature`, `X-Gitea-Event`). |
| 25 | +Push event pipeline: receive push event -> automatic clone/pull -> graph build -> DB persistence. |
| 26 | +Graceful shutdown: SIGINT/SIGTERM propagates context cancellation to in-progress clone/build work. |
27 | 27 |
|
28 | | -## CLI Skills (5개) |
| 28 | +## Agent Skills (5) |
29 | 29 |
|
30 | | -| Skill | 설명 | |
31 | | -| ---------------- | --------------------------------------------------------------------------------- | |
32 | | -| `/ccg` | 코어 빌드 & 검색 — 파싱, 그래프 빌드, 쿼리, 검색 | |
33 | | -| `/ccg-analyze` | 코드 분석 — 영향 반경, 플로우 추적, 데드코드, 아키텍처 | |
34 | | -| `/ccg-annotate` | 어노테이션 시스템 — AI 어노테이션 워크플로우, 태그 레퍼런스 | |
35 | | -| `/ccg-docs` | 문서 — 문서 생성, RAG 인덱싱, lint | |
36 | | -| `/ccg-workspace` | 네임스페이스 파일 관리 — 파일 업로드, 목록, 삭제 (`workspace`는 deprecated alias) | |
| 30 | +| Skill | Description | |
| 31 | +| ---------------- | ------------------------------------------------------------------------------------------- | |
| 32 | +| `/ccg` | Core build and search: parsing, graph build, query, search | |
| 33 | +| `/ccg-analyze` | Code analysis: impact radius, flow tracing, dead code, architecture | |
| 34 | +| `/ccg-annotate` | Annotation system: AI annotation workflow and tag reference | |
| 35 | +| `/ccg-docs` | Documentation: doc generation, RAG indexing, lint | |
| 36 | +| `/ccg-workspace` | Namespace file management: upload, list, delete (`workspace` is a deprecated alias) | |
37 | 37 |
|
38 | | -주요 커맨드: |
| 38 | +Skill files are located under `skills/` and are written so coding agents such as Codex and Claude Code |
| 39 | +can use them as slash-command style workflows. |
39 | 40 |
|
40 | | -- `ccg build [dir]` — 코드 그래프 빌드 (`--exclude`, `--no-recursive` 지원) |
41 | | -- `ccg docs [--out dir]` — 마크다운 문서 및 기본 RAG 인덱스 생성 |
42 | | -- `ccg rag-index [--out dir]` — 이미 계산된 커뮤니티와 생성 문서 기반 RAG 인덱스 생성 |
43 | | -- `ccg search <query>` — 전문 검색 (어노테이션 포함) |
44 | | -- `ccg lint [--strict]` — 문서 품질 체크 |
45 | | -- `ccg annotate [file|dir]` — AI 어노테이션 생성 |
| 41 | +Main commands: |
46 | 42 |
|
47 | | -`.ccg.yaml`로 exclude 패턴, DB 설정 등을 프로젝트 기본값으로 관리할 수 있습니다. |
| 43 | +- `ccg build [dir]` - build the code graph (supports `--exclude`, `--no-recursive`) |
| 44 | +- `ccg docs [--out dir]` - generate Markdown documentation and the default RAG index |
| 45 | +- `ccg rag-index [--out dir]` - build a RAG index from precomputed communities and generated docs |
| 46 | +- `ccg search <query>` - full-text search (includes annotations) |
| 47 | +- `ccg lint [--strict]` - check documentation quality |
| 48 | +- `/ccg-annotate annotate [file|dir]` - AI annotation generation workflow |
| 49 | +- `ccg example [language]`, `ccg tags` - annotation examples and tag reference |
48 | 50 |
|
49 | | -## 코드 검색 규칙 |
| 51 | +Use `.ccg.yaml` to manage project defaults such as exclude patterns and DB settings. |
50 | 52 |
|
51 | | -코드 위치, 관련 구현, 호출 관계, 영향 범위, 아키텍처 맥락을 찾을 때는 먼저 ccg MCP 도구와 CLI Skills를 활용합니다. |
| 53 | +## Code Search Rules |
52 | 54 |
|
53 | | -- 자연어 기반 코드 이해, 모듈 탐색, 아키텍처 맥락 수집은 `/ccg-docs` skill과 `retrieve_docs`, `get_rag_tree`, `get_doc_content`를 우선 사용합니다. |
54 | | -- 정확한 심볼 위치, 호출 관계, 그래프 메타데이터 확인은 ccg MCP `query_graph`, `get_node`, `get_minimal_context` 또는 `/ccg` skill을 사용합니다. |
55 | | -- 어노테이션/키워드 기반 후보 검색은 ccg MCP `search` 또는 `ccg search`를 보조로 사용합니다. |
56 | | -- 영향 범위, 플로우, 데드코드, 구조 분석은 `/ccg-analyze` skill과 관련 MCP 도구(`get_impact_radius`, `trace_flow`, `find_dead_code`, `get_architecture_overview`)를 우선 사용합니다. |
57 | | -- 단순 문자열 확인, 파일 존재 확인, ccg 인덱스가 없거나 오래된 경우에는 `rg`를 보조로 사용하고, 필요한 경우 `ccg build .` 또는 `ccg update .`로 그래프를 갱신합니다. |
| 55 | +When looking for code locations, related implementations, call relationships, impact radius, or architecture context, |
| 56 | +use ccg MCP tools and Agent Skills first. |
58 | 57 |
|
59 | | -## 문서 |
| 58 | +- For natural-language code understanding, module exploration, and architecture context, prefer the `/ccg-docs` skill and `retrieve_docs`, `get_rag_tree`, `get_doc_content`. |
| 59 | +- For exact symbol locations, call relationships, and graph metadata, use ccg MCP `query_graph`, `get_node`, `get_minimal_context`, or the `/ccg` skill. |
| 60 | +- For annotation/keyword-based candidate search, use ccg MCP `search` or `ccg search` as a supplement. |
| 61 | +- For impact radius, flows, dead code, and structural analysis, prefer the `/ccg-analyze` skill and related MCP tools (`get_impact_radius`, `trace_flow`, `find_dead_code`, `get_architecture_overview`). |
| 62 | +- For simple string checks, file existence checks, or cases where the ccg index is missing or stale, use `rg` as a supplement. If needed, refresh the graph with `ccg build .` or `ccg update .`. |
60 | 63 |
|
61 | | -상세 문서는 `guide/` 디렉토리를 참조하세요: |
| 64 | +## Documentation |
62 | 65 |
|
63 | | -- [CLI Reference](guide/cli-reference.md) — 전체 명령어, 플래그, 설정 파일 |
64 | | -- [MCP Tools](guide/mcp-tools.md) — 35개 MCP 도구, Skills, AI-Driven Annotation |
65 | | -- [Annotations](guide/annotations.md) — 어노테이션 태그, 예시, 검색 |
66 | | -- [Webhook](guide/webhook.md) — Webhook sync, 브랜치 필터링, HMAC, graceful shutdown |
67 | | -- [Docker](guide/docker.md) — Docker 빌드, MCP 서버, PostgreSQL 배포 |
68 | | -- [Development](guide/development.md) — 개발 가이드, Integration test, 프로젝트 구조 |
69 | | -- [Architecture](guide/architecture.md) — 데이터 흐름, 컴포넌트, DB 스키마 |
| 66 | +See the `guide/` directory for detailed documentation: |
70 | 67 |
|
71 | | -## 개발 규칙 |
| 68 | +- [CLI Reference](guide/cli-reference.md) - all commands, flags, and config files |
| 69 | +- [MCP Tools](guide/mcp-tools.md) - 35 MCP tools, Agent Skills, AI-Driven Annotation |
| 70 | +- [Annotations](guide/annotations.md) - annotation tags, examples, and search |
| 71 | +- [Webhook](guide/webhook.md) - webhook sync, branch filtering, HMAC, graceful shutdown |
| 72 | +- [Docker](guide/docker.md) - Docker builds, MCP server, PostgreSQL deployment |
| 73 | +- [Development](guide/development.md) - development guide, integration tests, project structure |
| 74 | +- [Architecture](guide/architecture.md) - data flow, components, DB schema |
72 | 75 |
|
73 | | -- TDD: Red → Green → Refactor |
74 | | -- Tidy First: 구조적 변경과 행위 변경 분리 |
75 | | -- GORM 쿼리만 사용 (raw SQL 금지) |
76 | | -- 테스트: `CGO_ENABLED=1 go test -tags "fts5" ./... -count=1` |
77 | | -- Integration test: `./scripts/integration-test.sh` (Gitea + PostgreSQL + ccg Docker 전체 파이프라인) |
| 76 | +## Development Rules |
78 | 77 |
|
79 | | -## 코드 작성 규칙 |
| 78 | +- TDD: Red -> Green -> Refactor |
| 79 | +- Tidy First: separate structural changes from behavioral changes |
| 80 | +- Use GORM queries only (no raw SQL) |
| 81 | +- Tests: `CGO_ENABLED=1 go test -tags "fts5" ./... -count=1` |
| 82 | +- Integration test: `./scripts/integration-test.sh` (full Gitea + PostgreSQL + ccg Docker pipeline) |
80 | 83 |
|
81 | | -새 코드를 생성하거나 기존 코드의 의미 있는 동작을 바꿀 때는 CCG annotation을 함께 작성합니다. |
| 84 | +## Code Writing Rules |
82 | 85 |
|
83 | | -우선순위: |
| 86 | +When creating new code or making meaningful behavior changes to existing code, add CCG annotations as well. |
84 | 87 |
|
85 | | -- 패키지/파일의 역할이 드러나야 하면 `// @index ...` |
86 | | -- 새 public type/function/method, MCP handler, CLI command, service method에는 `// @intent ...` |
87 | | -- 입력/출력 계약이 중요한 함수에는 `// @param`, `// @return` |
88 | | -- 사전 조건/보장 조건이 중요한 경우 `// @requires`, `// @ensures` |
89 | | -- 파일, DB, 네트워크, 캐시, 로그, 프로세스 등 외부 상태를 바꾸면 `// @sideEffect` |
90 | | -- receiver나 인자로 받은 값을 변경하면 `// @mutates` |
91 | | -- 비즈니스 규칙, 운영 정책, false-positive/false-negative 판단 기준은 `// @domainRule` |
92 | | -- 관련 핸들러/서비스/모델이 있으면 `// @see` |
| 88 | +Priority: |
93 | 89 |
|
94 | | -Annotation은 코드의 동작과 맞아야 하며, 설명을 부풀리지 않습니다. 단순 getter/setter나 자명한 한 줄 helper에는 억지로 붙이지 않습니다. |
| 90 | +- Use `// @index ...` when the package/file role should be discoverable. |
| 91 | +- Use `// @intent ...` for new public types/functions/methods, MCP handlers, CLI commands, and service methods. |
| 92 | +- Use `// @param`, `// @return` when input/output contracts matter. |
| 93 | +- Use `// @requires`, `// @ensures` when preconditions or guarantees matter. |
| 94 | +- Use `// @sideEffect` when the code mutates external state such as files, DB, network, cache, logs, or processes. |
| 95 | +- Use `// @mutates` when the receiver or argument values are modified. |
| 96 | +- Use `// @domainRule` for business rules, operational policies, and false-positive/false-negative criteria. |
| 97 | +- Use `// @see` when related handlers, services, or models exist. |
95 | 98 |
|
96 | | -## 작업 완료 체크 |
| 99 | +Annotations must match the code behavior and should not exaggerate the explanation. |
| 100 | +Do not force annotations onto simple getters/setters or obvious one-line helpers. |
97 | 101 |
|
98 | | -코드 생성/수정 작업을 완료하면 기본적으로 다음을 실행합니다. |
| 102 | +## Completion Checklist |
| 103 | + |
| 104 | +After completing code generation or code modifications, run the following by default: |
99 | 105 |
|
100 | 106 | ```bash |
101 | 107 | ccg build . |
102 | 108 | ccg docs --out docs |
103 | 109 | ccg lint |
104 | 110 | ``` |
105 | 111 |
|
106 | | -동작 변경이나 DB/검색/파서/MCP 핸들러 변경이 있으면 Go 테스트도 함께 실행합니다. |
| 112 | +If the change modifies behavior or touches DB/search/parser/MCP handlers, also run Go tests: |
107 | 113 |
|
108 | 114 | ```bash |
109 | 115 | CGO_ENABLED=1 go test -tags "fts5" ./... -count=1 |
110 | 116 | ``` |
111 | 117 |
|
112 | | -문서만 수정한 작업은 `ccg docs` 재생성과 `ccg lint`를 우선하고, 코드 테스트는 변경 범위에 따라 생략할 수 있습니다. |
| 118 | +For documentation-only changes, prioritize regenerating docs with `ccg docs` and running `ccg lint`. |
| 119 | +Code tests may be skipped depending on the change scope. |
0 commit comments