cgraphx 1.4.1 → 2.0.0

package/dist/.claude-template/skills/write-unit-test-spec/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: write-unit-test-spec
+description: 基于 spec 产出单元测试规格文档(零代码依赖)。读 spec 派生必测路径/边界/异常/期望,产出 <前缀>-单元测试-spec.md,每条场景标 spec 依据。完全不碰业务实现代码 —— 只看测试基建(测试目录/框架/既有测试风格)。产物是独立的测试规格契约,供后续 write-unit-test-code 填实测试代码消费。即使代码一行没写也能产出。Use when 写完 spec 想要单元测试规格 / 测试设计 / 测试范围清单 / 测试场景 / write-unit-test-spec. 不写测试代码、不读实现代码、不跑测试.
+---
+
+# Write Unit Test Spec
+
+## 定位
+
+**测试规格产出 skill**:基于 spec 派生"该测什么",产出独立的测试规格文档。完全不碰业务实现代码,只看项目的测试基建(测试目录、框架、既有测试风格)。
+
+**和 write-unit-test-code 的分工**:
+- 本 skill(write-unit-test-spec):产**测试规格文档**(该测哪些场景,基于 spec)
+- write-unit-test-code:基于测试规格 + 已有实现代码,填实测试代码 + 跑测试 + 出报告
+
+两个 skill 顺序依赖:先跑本 skill 拿规格,审完后跑 write-unit-test-code 填实。用户可以在中间叫停(只产规格,不填实)。
+
+## HARD-GATE
+
+- **不读业务实现代码** —— 本 skill 只读 spec 和测试基建(测试目录/框架/既有测试风格),不碰业务实现。测试规格是"该测什么",和代码怎么实现无关
+- **不写测试代码** —— 本 skill 只产 markdown 规格文档,测试代码是 write-unit-test-code 的事
+- **不编造测试场景** —— 每条必测场景必须能追溯到 spec 的某条验收口径,标 `依据: spec §X.Y`
+- **不强制使用** —— 纯增量可选环节,不跑不影响原流程
+- **依赖 spec** —— 当前 feature 没有 `<前缀>-spec.md` 时,提示"本 skill 依赖 spec,请先跑 write-spec"并退出
+
+## Trigger
+
+**使用此 skill 当**:
+- 用户做完 spec,想要测试规格 / 测试设计 / 测试范围清单
+- 用户想基于 spec 派生必测场景,审阅后再决定是否填实测试代码
+- 用户明确说"写测试规格 / 测试场景 / 测试设计 / write-unit-test-spec"
+
+**不要使用此 skill 当**:
+- 没有 spec —— 先跑 `/write-spec`
+- 想直接写测试代码 —— 用 `/write-unit-test-code`(但前提是已有测试规格)
+- 想跑测试 —— 用 `/write-unit-test-code`(它收尾会跑)
+- 纯文档 / 配置 / 无行为变更的需求 —— 无可测代码
+
+## 流程
+
+### 1. 前置检查
+
+- 确认 `docs/features/<feature-id>/<前缀>-spec.md` 存在。不存在 → 提示并退出。
+- 复用 spec 的 feature-id 和文件前缀,推导出本 skill 的产物文件名 `<前缀>-单元测试-spec.md`。
+
+### 2. 识别项目测试基建(不读业务实现)
+
+读项目的测试**基建**约定,决定测试代码未来放哪、用什么框架、什么命名。识别路径(按顺序尝试,任意一步识别到就停):
+
+- 读 `package.json` 的 `test` script → 推断框架(vitest/jest/mocha)和测试命令
+- 找既有测试目录:`__tests__/` / `test/` / `tests/` / `spec/`
+- 读 1-2 个既有测试文件 → 推断命名风格、describe/it 用法、文件后缀(只看测试代码风格,不看被测代码)
+- 非 JS 项目(python/go/rust)按该语言约定探测(pytest / go test / cargo test)
+- 探测不到 → 问用户"测试文件放哪?用什么命名?"
+
+识别结果作为测试规格文档里"测试骨架映射"节的依据(告诉 write-unit-test-code 未来测试文件该放哪)。
+
+### 3. 读 spec 提取测试关注点(只读 spec)
+
+从 `<前缀>-spec.md` 的以下章节派生必测路径:
+- 验收标准与测试关注点
+- 异常与边界场景
+- 业务规则(每条规则通常对应至少一个测试)
+- 系统行为(前置条件、触发、输出、失败行为)
+
+把派生出的测试场景按"主路径 / 边界 / 异常"分组,每个场景标 spec 依据。
+
+### 4. 产出测试规格文档
+
+写到 `docs/features/<feature-id>/<前缀>-单元测试-spec.md`。结构轻量,至少包含:
+
+- 测试范围(测什么、不测什么)
+- 必测场景清单(按 主路径/边界/异常 分组,每条标 spec 依据)
+- 测试骨架映射(未来测试文件路径 `<项目测试目录>/<feature-id>.test.ts` + 每个场景在骨架里的位置)
+- 待确认项(spec 不够细时标【待确认】,提示用户回 write-spec 补)
+
+**AI 自己发挥的空间**:具体章节怎么组织、必测场景写多细,agent 按 feature 复杂度判断。简单需求轻量写,复杂需求完整写。
+
+### 5. 汇报 + 不自动继续
+
+告诉用户:
+- 测试规格文档路径
+- 必测场景数(主路径 / 边界 / 异常 各几个)
+- 待确认项(如有)
+- 下一步建议:"审阅规格后,可跑 `/write-unit-test-code` 填实测试代码"
+
+**不调用 write-unit-test-code / implementation / write-plan**,由用户决定。
+
+## 产物
+
+| 产物 | 路径 | 形态 |
+|---|---|---|
+| 测试规格文档 | `docs/features/<feature-id>/<前缀>-单元测试-spec.md` | 人读 markdown,每条必测场景标 spec 依据 + 测试骨架映射 |
+
+## 边界场景
+
+- **spec 不够细** → 测试规格里标【待确认】,提示用户回 write-spec 补,或本 skill 内问 3-5 个关键问题。不硬编造测试场景。
+- **已有同模块测试规格文档** → 覆盖前提示用户"已有 <X>-单元测试-spec.md,是否覆盖",不静默覆盖。
+- **跨语言项目** → 在规格里标注"本次规格按 <语言> 测试约定写",如果 spec 跨多语言,问用户主语言。
+- **纯文档/配置需求** → 检测到 spec 无可测行为 → 提示"本需求无可测代码,不建议用本 skill"并退出。
+
+## 不做的事
+
+- 不读业务实现代码(只看测试基建)
+- 不写测试代码(只产规格 markdown)
+- 不跑测试
+- 不填实断言
+- 不改 spec / implementation / write-plan
+- 不假设测试框架(运行时探测)
+
+## 和其他 skill 的关系
+
+- **write-spec**:上游,提供输入。
+- **write-unit-test-code**:下游,消费本 skill 的测试规格文档,填实测试代码 + 跑测试 + 出报告。
+- **implementation**:平行线路,写业务实现代码。本 skill 不依赖它(规格可早于实现产出)。

package/dist/.claude-template/skills/write-workload/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: write-workload
+disable-model-invocation: true
+description: 产出「需求工作量汇报」文档,用于内部对账 / 甲方结款依据。当用户交付完一个需求、需要向甲方或内部汇报工作量、出结款依据、算工时、对账,或说「汇报工作量 / 需求工作量 / 工时汇报 / 工时统计 / 结款 / 对账 / 向甲方汇报 / 工作量评估 / 做了多少东西 / 值多少钱 / effort report / workload report / billing」时使用。即使没有明说「结款」,只要意图是量化已交付工作并对外汇报,就用本 skill。流程核心:先摸清汇报口径定维度(不直接开写),查代码核实交付物防虚报,补工时每项配理由+对应交付物,输出工作量汇报文档(含工时拆解+合理性佐证+可核验交付物,章节按需求复杂度组装,不套固定模板)到需求目录。对账场景必须有工时合理性佐证以应对「几个文件要这么多天」的质疑,工时数字不得凭空编造。
+---
+
+# write-workload — 需求工作量汇报(对账 / 结款)
+
+把一个**已交付的需求**量化成一份经得起甲方/财务追问的工作量汇报,作为内部对账、结款依据。
+
+## 这个 skill 的灵魂(先读这段)
+
+用户说「汇报工作量」时,最自然的反应是直接开写一份工时表。**别这样**。这个 skill 的全部价值在于五条心法,它们是从实战里踩出来的,每一条都对应一个真实翻车点:
+
+1. **维度先于内容** — 受众和口径不同,骨架完全不同(给业务方讲进度 / 给财务对账 / 给技术评审是三套东西)。直接写必返工。所以第一步永远是**问清口径再动笔**,哪怕只问两三个问题。
+2. **对账必配佐证** — 结款场景最致命的反问是「就改了这几个文件,要 X 人天?」。**代码量小但工时不少是常态**,因为联调、契约核实、外部对接都不体现在代码行数。工时拆解骨架如果不配一层「影响范围佐证」,工时数字就站不住。
+3. **隐性工时显性化** — 把代码里看不见的工作逐项列成工时项:需求待确认项的逐一核实、外部接口联调、跨服务契约逆向确认、配置映射纠正、返回键核对、多场景自测。**这是「工时比代码看着多」的合法性来源**,也是佐证层的主干。
+4. **工时数字不编** — 结款是钱。**你(Claude)不能凭空给工时数字。** 要么用户给真实记录,要么用户明确授权「你来估」并给区间,你才能填且标注是估算。被发现编数字是对账场景的信任灾难。
+5. **查代码核实交付物** — 需求文档 / plan 和实际代码经常有出入(方法名、URL、响应结构、映射表、查询方式都可能被改过)。不核实就按文档报,会虚报或错报,对账时穿帮。**汇报前必须回代码核实每一项交付物真实存在。**
+
+把这五条内化后,下面的流程就是它们的展开。
+
+## 何时触发
+
+- 用户交付完一个需求,要向甲方 / 内部出工作量汇报、结款依据、工时统计。
+- 关键词:工作量汇报 / 需求工作量 / 工时(汇报|统计) / 结款 / 对账 / 向甲方汇报 / 工作量评估 / 做了多少东西 / effort / workload / billing。
+- 即使没明说「结款」,只要意图是**量化已交付工作并对外汇报**,就走本 skill。
+
+> 不触发:纯进度同步(轻量,几句话即可)、未交付的纯技术方案评估(走 write-spec/plan)、代码质量评审(走 code-review)。
+
+## 输入
+
+一个需求,通常在 `docs/features/<feature-id>/` 下,含:需求文档 / spec / plan / 已落地代码。用户也可能只给一个需求编号或一句话描述,需要你先定位需求目录。
+
+## 流程
+
+### Step 0 · 摸清汇报口径(先问,不先写)
+
+这是最关键的一步,跳过它后面全错。用 `AskUserQuestion` 一次性问清(2~3 个问题):
+
+- **受众是谁?** — 内部对账/财务(要量化、可核验)/ 甲方项目经理(要进度+数字)/ 甲方技术负责人(要方案合理性)/ 内部领导。受众决定深度和口径。
+- **代码处于什么阶段?** — 已联调自测通过 / 代码写完未联调 / 还没写只是预估。决定汇报是「已交付」还是「预估」。
+- **结款按什么口径?** — 任务工时拆解(T&M,按人天)/ 交付物计价(按交付的文件接口)/ 功能点法。决定主维度骨架。
+
+> 问问题的目的不是走流程,是让骨架选对。问完你心里要有数:这份报告主维度是什么、要不要加固层、工时数字从哪来。
+
+### Step 1 · 读需求 + 查代码核实交付物
+
+1. 读需求文档 / spec / plan,理清这个需求做了什么。
+2. **用 grep / read 核实代码**:
+   - 核实每一项交付物**真实存在**:接口、实现类、新建文件、MDA 常量、配置、外部对接。
+   - **识别 plan / 需求文档与实际代码的出入**(方法名变没变?URL 对不对?响应结构是平铺还是嵌套?映射表准不准?批量查询方式?)。这些出入既是核实,也是隐性工时的来源(纠正它们花了时间)。
+3. 核实跨服务契约:依赖的下游服务方法是否真按预期返回(返回键、分支逻辑)。
+
+> 这一步的产出是一份「真实的交付物清单 + plan 与代码的 diff」。后面工时和佐证都基于它,不是基于需求文档的描述。
+
+### Step 2 · 定维度与骨架
+
+基于 Step 0 的口径选主维度骨架。**用 `AskUserQuestion` 带 preview 让用户对比骨架**(preview 里放每种骨架的报告结构 ASCII 图,用户一眼能选):
+
+- **任务工时拆解 + 影响范围佐证**(结款/对账默认推荐):工时拆解为主,叠加跨服务/外部对接佐证层,人天作汇总。
+- **交付物 + 影响范围**:以客观交付物(文件/接口/外部对接/测试)为主轴,影响范围作定价加权。适合交付物计价/验收结款。
+- **功能点法**:EI/EO/EQ/EIF/ILF 估算 UFP → 复杂度加权 → 折算人天。适合大型正式验收,单接口偏重。
+
+> 为什么用 preview:骨架的差别用文字讲不清,但用结构图对比用户一秒就能选。别省这一步。
+
+### Step 3 · 定内容策略
+
+两个决策(可并入 Step 2 的提问):
+
+- **工时口径**:按真实报(代码看着少但实际多,差额靠佐证解释)/ 按预估(还没做,给区间)。
+- **要不要加固层**:对账场景**默认要加**影响范围佐证层,这是对冲「几个文件要这么多天」的唯一手段。
+
+### Step 4 · 补工时
+
+参见下方「工时补全规则」。**数字不编,每项配理由 + 对应交付物。**
+
+### Step 5 · 出文档
+
+按「文档结构:必含要素 + 按需组装」组织章节(不套固定模板),保存到需求目录(见「hx 项目约定」的命名规则)。
+
+## 工时补全规则
+
+- **每项工时落在 0.5~2 天**(用户给的范围默认值,可按项目调整),超出要拆分或说明。
+- **每项必须配三件套**:工时数字 + 一句话理由(为什么是这个天数)+ 对应交付物(可核验,指向具体文件/接口/外部对接)。三件套缺一不可,这是对账时逐项核对的依据。
+- **数字来源优先级**:
+  1. 用户给真实人天记录 → 直接填。
+  2. 用户授权「你来估」+ 给区间 → 你按代码复杂度和隐性成本估,每项标注理由,**合计处可注明「估算」**。
+  3. **都没有 → 不填数字,留 `[__]` 占位并明确告诉用户「这是核心数字,我不编,你填」。** 绝不凭空写一个看似合理的数。
+- **隐性工时必须显性化成独立工时项**:需求待确认项核实、外部接口对接联调、跨服务契约逆向确认、配置/映射纠正、返回键核对、多场景自测 —— 这些代码行数小但耗时大,是工时主要构成,**必须单列**,不能藏在「开发」一项里。
+- **总量自检**:合计 ÷ 交付物数量 是否合理?隐性工时占比是否说得通?如果总数看起来「虚」,要么补佐证,要么调数字,别硬交。
+
+## 文档结构:必含要素 + 按需组装(不要套固定章节)
+
+不同需求的章节不一样——单服务小改动和跨服务外部对接的汇报,章节数、标题、侧重都不同。**别强行套固定模板。** 但结款汇报有几个必含的逻辑要素,缺了就不合格;其余按需求伸缩。
+
+### 必含要素(逻辑闭环,缺一不可)
+1. **工时拆解**(主维度)—— 结款的核心数字。用工时三件套(任务项 / 工时 / 理由 / 对应交付物)。
+2. **工时合理性佐证** —— 对冲「几个文件要这么多天」。形式自由:可独立成节,也可融进工时表「理由」列(每项配了为什么,本身就是佐证)。跨服务 / 外部对接 / 隐性工时多时,建议独立成节把隐性工时摊开。
+3. **可核验交付物清单** —— 文件 / 接口 / 外部对接 / 测试,让每条工时能对照到实物。
+4. **工时数字来源声明** —— 心法 #4。一句话注明:真实记录 还是 估算。
+
+### 按需要素(看情况取舍)
+- **需求背景**:给非技术读者(财务)或需求复杂时写;简单需求 / 技术读者一句带过或省略。
+- **影响范围**(跨服务 / 外部对接):跨度大单独成节;单服务改动并入工时理由即可。
+- **遗留 / 风险**:有就写,没有不硬凑。
+
+### 组织原则
+- 章节数量、标题、合并 / 拆分**按需求定,没有固定形态**。唯一不能省的是上面四个必含要素的**逻辑**(形式可变)。
+- 简单需求(单服务、小改动):工时表(理由列即佐证)+ 交付物清单,两节足矣。
+- 复杂需求(跨服务 / 外部对接):工时拆解 + 独立佐证节 + 交付物 + 遗留,四到五节。
+
+> 复杂需求四到五节的范例见下方「真实样例」(req74442)。那是「一种」组织方式,不是「唯一」模板。
+
+## 项目约定
+
+- **需求目录**:`docs/features/<feature-id>/`。先定位用户给的 feature 目录。
+- **文件命名**:`<前缀>-需求工作量.md`。**前缀沿用该需求目录里已有文件的命名前缀**(如 `CRM-req74442-电渠批量违约金试算接口`),保持族内一致。保存到该需求目录根下(不进 plan/ 子目录)。
+- **查代码**:用 grep / Read;跨服务契约定要分别核实每个服务。
+- **元信息表日期**:用当天日期(会话上下文里的 currentDate)。
+- **术语对齐**:用 CLAUDE.md 和 docs/knowledge/ 里的项目术语(prodInst / offer / bizCode / atom / @Center 等),别自造。
+
+## 收尾自检(交文档前)
+
+- [ ] 主维度和受众口径匹配(Step 0 确认过)
+- [ ] 每项工时有三件套,数字有来源(没编)
+- [ ] 工时合理性佐证在(独立成节 或 融进工时表理由列),能回答「几个文件要这么多天」
+- [ ] 交付物清单每一项都核实过真实存在
+- [ ] 文件名前缀和需求目录族内一致,存对位置
+- [ ] 遗留/风险如实写(测试地址待切生产、入参口径出入等),不藏

package/dist/cli/fatal-handler.d.ts

@@ -0,0 +1,21 @@
+/**
+ * Render an uncaught value for the last-resort log WITHOUT triggering
+ * stack formatting. Pure and total — never throws, never touches `.stack`.
+ */
+export declare function describeFatal(value: unknown): string;
+/** Injectable seams so the wiring is testable without registering real handlers. */
+export interface FatalHandlerDeps {
+    /** Event target to attach to. Defaults to `process`. */
+    target?: NodeJS.EventEmitter;
+    /** How to terminate. Defaults to `process.exit`. */
+    exit?: (code: number) => void;
+    /** How to emit the bounded line. Defaults to a synchronous fd-2 write. */
+    write?: (line: string) => void;
+}
+/**
+ * Install the uncaught-exception / unhandled-rejection handlers. Both
+ * log a bounded line and then exit non-zero (Node's default fatal
+ * semantics).
+ */
+export declare function installFatalHandlers(deps?: FatalHandlerDeps): void;
+//# sourceMappingURL=fatal-handler.d.ts.map

package/dist/cli/fatal-handler.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"fatal-handler.d.ts","sourceRoot":"","sources":["../../src/cli/fatal-handler.ts"],"names":[],"mappings":"AAyBA;;;GAGG;AACH,wBAAgB,aAAa,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CAcpD;AAWD,oFAAoF;AACpF,MAAM,WAAW,gBAAgB;IAC/B,wDAAwD;IACxD,MAAM,CAAC,EAAE,MAAM,CAAC,YAAY,CAAC;IAC7B,oDAAoD;IACpD,IAAI,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IAC9B,0EAA0E;IAC1E,KAAK,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;CAChC;AAED;;;;GAIG;AACH,wBAAgB,oBAAoB,CAAC,IAAI,GAAE,gBAAqB,GAAG,IAAI,CActE"}

package/dist/cli/fatal-handler.js

@@ -0,0 +1,109 @@
+"use strict";
+var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    var desc = Object.getOwnPropertyDescriptor(m, k);
+    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
+      desc = { enumerable: true, get: function() { return m[k]; } };
+    }
+    Object.defineProperty(o, k2, desc);
+}) : (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    o[k2] = m[k];
+}));
+var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
+    Object.defineProperty(o, "default", { enumerable: true, value: v });
+}) : function(o, v) {
+    o["default"] = v;
+});
+var __importStar = (this && this.__importStar) || (function () {
+    var ownKeys = function(o) {
+        ownKeys = Object.getOwnPropertyNames || function (o) {
+            var ar = [];
+            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
+            return ar;
+        };
+        return ownKeys(o);
+    };
+    return function (mod) {
+        if (mod && mod.__esModule) return mod;
+        var result = {};
+        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
+        __setModuleDefault(result, mod);
+        return result;
+    };
+})();
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.describeFatal = describeFatal;
+exports.installFatalHandlers = installFatalHandlers;
+/**
+ * Last-resort handlers for uncaught exceptions and unhandled rejections.
+ *
+ * Reaching one of these means a fault escaped every boundary (per-request
+ * try/catch in command actions, schema-bootstrap's own error types, the
+ * timeline hook layer's fail-silent contract) — i.e. the process is in an
+ * undefined state. Node's default in that case is to print and exit
+ * non-zero; this module restores that safe default after logging a
+ * BOUNDED, hang-proof line.
+ *
+ * Two properties are load-bearing and covered by tests:
+ *   1. {@link describeFatal} never reads `error.stack` and never hands the
+ *      raw Error to `console.*`. The lazy stack getter can loop forever
+ *      inside this handler; touching it could block the very `exit()`
+ *      below. Name + message are plain string properties and are always
+ *      safe.
+ *   2. We write synchronously to fd 2 and then exit, so the message is
+ *      flushed even though `process.exit()` doesn't drain async streams.
+ *
+ * Migrated from cgraphx 1.x (src/bin/fatal-handler.ts) — the handler is
+ * generic process-level infrastructure, independent of the code-graph
+ * layer that 2.0 removes.
+ */
+const fs = __importStar(require("fs"));
+/**
+ * Render an uncaught value for the last-resort log WITHOUT triggering
+ * stack formatting. Pure and total — never throws, never touches `.stack`.
+ */
+function describeFatal(value) {
+    if (value instanceof Error) {
+        const name = typeof value.name === 'string' && value.name ? value.name : 'Error';
+        // `message` is a plain own/proto string property — reading it does NOT
+        // format the stack.
+        const message = typeof value.message === 'string' ? value.message : '';
+        return message ? `${name}: ${message}` : name;
+    }
+    try {
+        return String(value);
+    }
+    catch {
+        // e.g. an object with a throwing `toString` / `Symbol.toPrimitive`.
+        return '<unstringifiable value>';
+    }
+}
+/** Best-effort synchronous stderr write that can never keep a doomed process alive. */
+function writeStderr(line) {
+    try {
+        fs.writeSync(2, line);
+    }
+    catch {
+        /* stderr closed/gone — nothing more we can safely do */
+    }
+}
+/**
+ * Install the uncaught-exception / unhandled-rejection handlers. Both
+ * log a bounded line and then exit non-zero (Node's default fatal
+ * semantics).
+ */
+function installFatalHandlers(deps = {}) {
+    const target = deps.target ?? process;
+    const exit = deps.exit ?? ((code) => process.exit(code));
+    const write = deps.write ?? writeStderr;
+    target.on('uncaughtException', (error) => {
+        write(`[cgraphx] Uncaught exception: ${describeFatal(error)}\n`);
+        exit(1);
+    });
+    target.on('unhandledRejection', (reason) => {
+        write(`[cgraphx] Unhandled rejection: ${describeFatal(reason)}\n`);
+        exit(1);
+    });
+}
+//# sourceMappingURL=fatal-handler.js.map

package/dist/cli/fatal-handler.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"fatal-handler.js","sourceRoot":"","sources":["../../src/cli/fatal-handler.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA6BA,sCAcC;AA0BD,oDAcC;AAnFD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,uCAAyB;AAEzB;;;GAGG;AACH,SAAgB,aAAa,CAAC,KAAc;IAC1C,IAAI,KAAK,YAAY,KAAK,EAAE,CAAC;QAC3B,MAAM,IAAI,GAAG,OAAO,KAAK,CAAC,IAAI,KAAK,QAAQ,IAAI,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,OAAO,CAAC;QACjF,uEAAuE;QACvE,oBAAoB;QACpB,MAAM,OAAO,GAAG,OAAO,KAAK,CAAC,OAAO,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,CAAC;QACvE,OAAO,OAAO,CAAC,CAAC,CAAC,GAAG,IAAI,KAAK,OAAO,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC;IAChD,CAAC;IACD,IAAI,CAAC;QACH,OAAO,MAAM,CAAC,KAAK,CAAC,CAAC;IACvB,CAAC;IAAC,MAAM,CAAC;QACP,oEAAoE;QACpE,OAAO,yBAAyB,CAAC;IACnC,CAAC;AACH,CAAC;AAED,uFAAuF;AACvF,SAAS,WAAW,CAAC,IAAY;IAC/B,IAAI,CAAC;QACH,EAAE,CAAC,SAAS,CAAC,CAAC,EAAE,IAAI,CAAC,CAAC;IACxB,CAAC;IAAC,MAAM,CAAC;QACP,wDAAwD;IAC1D,CAAC;AACH,CAAC;AAYD;;;;GAIG;AACH,SAAgB,oBAAoB,CAAC,OAAyB,EAAE;IAC9D,MAAM,MAAM,GAAG,IAAI,CAAC,MAAM,IAAI,OAAO,CAAC;IACtC,MAAM,IAAI,GAAG,IAAI,CAAC,IAAI,IAAI,CAAC,CAAC,IAAY,EAAE,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;IACjE,MAAM,KAAK,GAAG,IAAI,CAAC,KAAK,IAAI,WAAW,CAAC;IAExC,MAAM,CAAC,EAAE,CAAC,mBAAmB,EAAE,CAAC,KAAc,EAAE,EAAE;QAChD,KAAK,CAAC,iCAAiC,aAAa,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;QACjE,IAAI,CAAC,CAAC,CAAC,CAAC;IACV,CAAC,CAAC,CAAC;IAEH,MAAM,CAAC,EAAE,CAAC,oBAAoB,EAAE,CAAC,MAAe,EAAE,EAAE;QAClD,KAAK,CAAC,kCAAkC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;QACnE,IAAI,CAAC,CAAC,CAAC,CAAC;IACV,CAAC,CAAC,CAAC;AACL,CAAC"}

package/dist/cli/index.d.ts

@@ -0,0 +1,27 @@
+#!/usr/bin/env node
+/**
+ * cgraphx CLI — 2.0 main entry.
+ *
+ * Compiled to `./dist/cli/index.js` and wired as the `cgraphx` bin in
+ * package.json. The 2.0 command surface is the three reused subsystems
+ * (docs / db / timeline), the `init` / `status` project commands, the
+ * self-update `upgrade`, and the Claude Code `install` / `uninstall`
+ * flow.
+ *
+ * What was cut vs. the cgraphx 1.x lineage:
+ *   - every code-graph command (explore / query / node / callers /
+ *     callees / affected / index / sync / files / context / search / …)
+ *   - the MCP `serve` command (no server in 2.0)
+ *   - usage collection and the preAction usage-record hook (no collection in 2.0)
+ *   - `prompt-hook` (was a graph-front-load hook; no graph in 2.0)
+ *   - the WASM-runtime-flag re-exec (no extraction parser in 2.0)
+ *   - the Node 25 hard-block (the V8 turboshaft bug it guarded only fired
+ *     while compiling the extraction parser)
+ *
+ * What was kept: commander-based framing, ANSI helpers, the
+ * `installFatalHandlers` last-resort handler, the Node floor check, the
+ * no-args-runs-installer affordance, and the `-v` / `-version`
+ * spellings.
+ */
+export {};
+//# sourceMappingURL=index.d.ts.map

package/dist/cli/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/cli/index.ts"],"names":[],"mappings":";AACA;;;;;;;;;;;;;;;;;;;;;;;GAuBG"}