@c4a/extract 0.6.7 → 0.6.9

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
@@ -1,6 +1,16 @@
1
1
  # @c4a/extract
2
2
 
3
- Code extraction framework for Context. It owns the language-plugin protocol, repository runner, raw code snapshot contract, digest generation, and shared Tree-sitter parsing utilities.
3
+ [简体中文](./README.zh-CN.md)
4
+
5
+ `@c4a/extract` turns repository structure into deterministic evidence that a
6
+ Context knowledge workflow can review and explain. It owns the language-plugin
7
+ protocol, repository runner, raw code snapshot contract, digest generation, and
8
+ shared Tree-sitter parsing utilities.
9
+
10
+ It does not decide what code means to a product or audience and does not write
11
+ approved knowledge. Language plugins emit structural facts; the Context runtime
12
+ binds them to source identity, stages review candidates, and applies approved
13
+ knowledge through the normal lifecycle.
4
14
 
5
15
  ## Package Role
6
16
 
@@ -14,6 +24,20 @@ project extraction phases such as `extractTs({ source, collection: "codegraph" }
14
24
 
15
25
  **Depends on:** `@c4a/core`, `web-tree-sitter`, `zod`
16
26
 
27
+ ```text
28
+ confirmed repository boundary
29
+
30
+ language plugins + repository runner
31
+
32
+ versioned raw code snapshot
33
+
34
+ Context candidates → review → approved knowledge
35
+ ```
36
+
37
+ Knowledge-workspace users normally reach this package through the installed
38
+ Agent entry and a declared extraction phase. The runner protocol below is for
39
+ extractor authors, Context maintainers, and project-owned adapters.
40
+
17
41
  ## Protocol Layers
18
42
 
19
43
  ### 1. Language Plugin Protocol
@@ -0,0 +1,162 @@
1
+ # @c4a/extract
2
+
3
+ [English](./README.md)
4
+
5
+ `@c4a/extract` 将代码仓库结构转化为 Context 知识工作流可以审核和解释的确定性
6
+ 证据。它负责语言插件协议、仓库 Runner、原始代码快照契约、digest 生成和共用的
7
+ Tree-sitter 解析工具。
8
+
9
+ 它不判断代码对产品或读者意味着什么,也不写入正式知识。语言插件只输出结构事实;
10
+ Context 运行时将这些事实绑定到来源身份、暂存审核候选,并通过标准生命周期应用
11
+ 审核通过的知识。
12
+
13
+ ## 在知识生产链中的职责
14
+
15
+ ```text
16
+ 已确认的仓库边界
17
+
18
+ 语言插件 + Repository Runner
19
+
20
+ 版本化原始代码快照
21
+
22
+ Context 候选 → 审核 → 正式知识
23
+ ```
24
+
25
+ - 语言 package 实现 `ExtractionPlugin` 并返回 `ExtractionResult` v2。
26
+ - Runner 加载一个或多个插件,扫描仓库模块,输出 progress、module-error 和
27
+ summary 事件,并可生成底层代码快照。
28
+ - Context runtime 在知识项目声明提取阶段后调用 Runner。
29
+ - 草稿候选和运行快照留在 `.tmp/context-runtime/`;只有 review apply 会写入正式
30
+ Markdown。
31
+
32
+ 知识工作区用户通常通过已安装的 Agent 入口和声明好的提取阶段使用本包,不需要
33
+ 手工构造 Runner 输入。下面的协议主要面向提取器作者、Context 维护者和项目自有
34
+ Adapter。
35
+
36
+ **依赖:** `@c4a/core`、`web-tree-sitter`、`zod`
37
+
38
+ ## 协议层
39
+
40
+ ### 1. 语言插件协议
41
+
42
+ 语言 package 实现 `protocol.ts` 中的 `ExtractionPlugin`:
43
+
44
+ ```ts
45
+ interface ExtractionPlugin {
46
+ id: string;
47
+ languages: string[];
48
+ packageManagers: string[];
49
+ manifestTypes?: ManifestInfo["type"][];
50
+ canHandle(source: SourceInfo): boolean;
51
+ detectEntries(manifest: ManifestInfo, fs: FileSystem): Promise<EntryDetectionResult>;
52
+ extractSymbols(entries: EntryFile[], fs: FileSystem): Promise<ExtractionResult>;
53
+ detectPatterns?(fs: FileSystem): Promise<PatternDetectionResult>;
54
+ }
55
+ ```
56
+
57
+ 关键约束:
58
+
59
+ - 插件通过 `FileSystem` 读取,不直接访问 `node:fs`;
60
+ - `manifestTypes` 声明哪些 manifest 可以传给 `detectEntries()`;一个模块包含多种
61
+ manifest 时必须显式声明;
62
+ - `detectEntries()` 返回稳定的 package 身份、类型、语言、可选版本和入口文件;
63
+ - `extractSymbols()` 返回带稳定符号和关系的 `ExtractionResult` v2;
64
+ - `detectEntries()` 先于 `extractSymbols()` 调用,插件可以在两步之间保留本次检测
65
+ 的 package 上下文。
66
+
67
+ ### 2. ExtractionResult v2
68
+
69
+ 每个插件返回:
70
+
71
+ ```ts
72
+ {
73
+ version: "2",
74
+ meta: { extractedAt, pluginId, commitHash, language },
75
+ package: { name, kind, language, version? },
76
+ files: [{ path, language, lines }],
77
+ symbols: SymbolInfo[],
78
+ relations: RelationInfo[],
79
+ stats: { files, lines, exportedSymbols, internalSymbols, relations }
80
+ }
81
+ ```
82
+
83
+ `SymbolInfo` 保存符号身份、可见性、文件与行范围、成员、参数、返回类型、继承、
84
+ 实现、Props、联合值和源码文档。`RelationInfo` 可以表达 `imports`、
85
+ `imports_type`、`calls`、`extends`、`implements`、`param_type`、
86
+ `return_type`、`of_type`、`depends_on` 和 `contains` 等结构关系。
87
+
88
+ ### 3. Repository Runner
89
+
90
+ 包暴露底层 NDJSON Runner `c4a-extract-code`。正常知识工作区由当前 Route 和已声明
91
+ 阶段调用它;Agent 不应手工生成 stdin Payload。
92
+
93
+ Runner 输出一行一个 JSON 对象:
94
+
95
+ - `{ "type": "progress", "phase": "scanning|parsing|uploading", ... }`
96
+ - `{ "type": "module_error", ... }`
97
+ - `{ "type": "summary", "extraction": ..., "snapshot": ... }`
98
+ - `{ "type": "error", "code": "runner-failed", "message": "..." }`
99
+
100
+ Runner 不直接写 Context 工作区。它在 summary 中返回快照文件,由 Context runtime
101
+ 校验后原子写入。
102
+
103
+ ### 4. 原始代码快照
104
+
105
+ 启用 snapshot 输入后,Runner 生成:
106
+
107
+ | 文件 | 用途 |
108
+ |---|---|
109
+ | `source.yaml` | 代码来源 manifest |
110
+ | `manifest.json` | 契约版本、工具链、数量、hash 和 dirty 状态 |
111
+ | `_meta.yaml` | 兼容元数据和输入摘要 |
112
+ | `digests.jsonl` | 每个模块的版本化 digest |
113
+ | `source-files.jsonl` | 来源到模块和 digest 的映射 |
114
+ | `packages.jsonl` | package 身份、类型、语言、模块路径和可选版本 |
115
+ | `symbols.jsonl` | 扁平符号行,保留 package 和 module 字段 |
116
+ | `edges.jsonl` | 带 package、module、version 和 hash 的代码关系 |
117
+
118
+ Context runtime 在投影前校验快照契约。正式代码知识中的 Section 使用由这些索引
119
+ 派生的 `source_ref`,例如:
120
+
121
+ ```text
122
+ src-N#package:<package>@<hash>
123
+ src-N#symbol:<file>:<symbol>:<kind>@<hash>
124
+ ```
125
+
126
+ Agent 将完整 `source_ref` 当作不透明 token 复制,不自行解析或改写。
127
+
128
+ ## 编写新的语言插件
129
+
130
+ 创建类似 `@c4a/extract-python` 的 package 并导出 `ExtractionPlugin`。至少需要:
131
+
132
+ 1. 识别语言 manifest;
133
+ 2. 返回稳定 package 名、类型、语言和可用版本;
134
+ 3. 一个 manifest 表达嵌套布局时返回 `subPackages`;
135
+ 4. 解析公开入口,以区分 exported 和 internal 符号;
136
+ 5. 输出稳定的符号名、kind、visibility、文件和行范围;
137
+ 6. 输出导入、调用、类型、继承或使用关系;
138
+ 7. 插件内部保持 module-relative 路径,由 Runner 加上 repo-relative 前缀;
139
+ 8. 在项目提取阶段的 Runner 配置中注册插件。
140
+
141
+ ## 与 Context 项目提取的关系
142
+
143
+ `@c4a/extract` 位于项目提取阶段上游,不渲染正式知识。典型流程是:
144
+
145
+ 1. 用户确认代码来源边界;
146
+ 2. `src/index.ts` 声明相应提取阶段;
147
+ 3. 当前 Route 先运行 dry-run,展示解析出的模块、候选数量和知识路径;
148
+ 4. 正式提取生成待审候选和来源指纹;
149
+ 5. review apply 将批准内容写入正式知识;
150
+ 6. close、verify 和 build 完成本轮并生成知识包。
151
+
152
+ 因此,更好的符号和关系会产生更可靠的候选、证据引用和知识包,但业务分类继续由
153
+ Agent 与用户依据证据决定。
154
+
155
+ ## 开发
156
+
157
+ ```bash
158
+ bun run --filter @c4a/extract build
159
+ bun run --filter @c4a/extract typecheck
160
+ bun run --filter @c4a/extract test
161
+ bun run --filter @c4a/extract lint
162
+ ```
package/package.json CHANGED
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "@c4a/extract",
3
- "version": "0.6.7",
3
+ "version": "0.6.9",
4
4
  "type": "module",
5
- "description": "Code extraction engine Tree-sitter AST parsing and structural analysis",
5
+ "description": "Language-plugin framework and repository runner for Context code evidence",
6
6
  "license": "MIT",
7
7
  "repository": {
8
8
  "type": "git",