Fix lint errors and publish workflow

.github/workflows/ci.yml

@@ -44,3 +44,7 @@ jobs:
         run: test -f dist/packages/cli/index.js
       - name: Smoke test
         run: node dist/packages/cli/index.js --help
+      - name: CLI check (hello-world)
+        run: node dist/packages/cli/index.js check -r examples/hello-world
+      - name: CLI check (order-service)
+        run: node dist/packages/cli/index.js check -r examples/order-service

.github/workflows/publish.yml

@@ -7,7 +7,6 @@ on:
 jobs:
   publish:
     runs-on: ubuntu-latest
-    environment: npm
     permissions:
       contents: read
       id-token: write

README.md

@@ -22,7 +22,7 @@ L1  Code         最终实现
 
 SVP 不自己调 AI API，不造编译器。SVP 是 AI 编码工具（Claude Code、Cursor、Windsurf、Kimi Code、Codex、GitHub Copilot）的**增强层**：
 
-- **工具链**：`svp check`（校验）、store（读写）、hash（变更追踪）
+- **工具链**：`forge check`（校验）、store（读写）、hash（变更追踪）
 - **Skills**：基于五层数据模型生成结构化 context，喂给用户已有的 AI 工具
 
 类似 [OpenSpec](https://github.com/Fission-AI/OpenSpec) 的定位——不造 AI，给 AI 喂更好的上下文。SVP 的能力随 base model 进化自动提升。
@@ -73,15 +73,15 @@ npm run check    # tsc + eslint + prettier
 - [设计理由](docs/design-rationale.md) — 为什么这么设计，每个决策的推理过程
 - [代码风格](docs/code-style.md) — 开发规范（命名、测试、git、依赖、版本）
 - [交互架构](docs/interaction.md) — 逐层渗透模型、虚拟文件树、聚焦视图、编译计划
-- [check 错误码](docs/check-reference.md) — svp check 的所有错误/警告及修复建议
+- [check 错误码](docs/check-reference.md) — forge check 的所有错误/警告及修复建议
 
 ## 目录
 
 ```
 packages/
 ├── core/        五层数据模型的 TypeScript 类型定义 + 核心函数
 ├── skills/      Prompt 生成器（design-l3、compile、recompile 等）
-└── cli/         CLI 入口（svp 命令）
+└── cli/         CLI 入口（forge 命令）
 
 docs/            设计文档 + 开发规范
 examples/        示例项目（hello-world、order-service）

docs/architecture.md

@@ -89,7 +89,7 @@ interface L2CodeBlock {
 
 分界原则：**层间连接关系结构化，block 内部是黑盒。**
 
-结构化（`svp check` 校验）：
+结构化（`forge check` 校验）：
 - pins 的类型、wire 的引用、层间 block/flow 引用
 
 自然语言（展示给人看就行）：
@@ -125,7 +125,7 @@ L5 改了 intent
 
 自下而上（仅检测，用户决策）：
 L1 被手改
-  → L2 的 contentHash 和 L1 实际哈希不匹配 → svp check 报 CONTENT_DRIFT
+  → L2 的 contentHash 和 L1 实际哈希不匹配 → forge check 报 CONTENT_DRIFT
     → 用户决定：接受改动 / 回退 / 更新上层契约
 ```
 
@@ -141,7 +141,7 @@ L4/L3 的可视化编辑器。用节点图（nodes + wires）来编辑 L4 flow 
 
 svp-blueprint 不是一个"层"——它是数据模型的一种人看面（编辑视图）。未来可以有其他编辑器（CLI、Web IDE、VS Code 插件），底下操作的是同一份数据。
 
-### svp check
+### forge check
 
 校验层间连接关系：
 - pin 类型匹配
@@ -162,9 +162,9 @@ SVP 不自己调 AI API，而是生成结构化的 context（skills）喂给用
 
 SVP 不锁定任何 AI 提供商。今天用 Claude Code，明天用别的，SVP 数据模型不变。
 
-这个定位类似 [OpenSpec](https://github.com/Fission-AI/OpenSpec)——不造 AI，给 AI 喂更好的上下文。SVP 的差异在于：五层结构化的契约框架 + `svp check` 的形式化校验。
+这个定位类似 [OpenSpec](https://github.com/Fission-AI/OpenSpec)——不造 AI，给 AI 喂更好的上下文。SVP 的差异在于：五层结构化的契约框架 + `forge check` 的形式化校验。
 
-Skills 的具体实现形式是 SVP CLI 的虚拟文件树（`svp view`）和编译计划（`svp compile-plan`），详见 [交互架构](interaction.md)。
+Skills 的具体实现形式是 SVP CLI 的虚拟文件树（`forge view`）和编译计划（`forge compile-plan`），详见 [交互架构](interaction.md)。
 
 ### SVP 交互架构
 

docs/check-reference.md

@@ -1,6 +1,6 @@
-# svp check 错误码参考
+# forge check 错误码参考
 
-`svp check` 校验 `.svp/` 目录下所有层的数据一致性。以下是所有可能的错误和警告。
+`forge check` 校验 `.svp/` 目录下所有层的数据一致性。以下是所有可能的错误和警告。
 
 ## 错误（Error）
 

docs/compilation.md

@@ -19,7 +19,7 @@ L3Block ──→ AI 编码工具 + SVP skills ──→ L2CodeBlock + L1 源文
 
 SVP 不自己调 AI API。契约盒（validate + constraints + description）作为结构化 context 喂给 AI 工具，AI 工具负责生成代码。
 
-> **注意区分两种"编译"**：本文档描述的是**格式转换编译**（YAML 节点图 → L3/L4 JSON），是确定性的、不需要 AI 的。变更驱动的**重编译计划**（某层改了 → 计算哪些下层需要重新生成）见 [交互架构](interaction.md) 的 `svp compile-plan` 章节。
+> **注意区分两种"编译"**：本文档描述的是**格式转换编译**（YAML 节点图 → L3/L4 JSON），是确定性的、不需要 AI 的。变更驱动的**重编译计划**（某层改了 → 计算哪些下层需要重新生成）见 [交互架构](interaction.md) 的 `forge compile-plan` 章节。
 
 ## 映射规则
 
@@ -195,7 +195,7 @@ interface OrderRequest {
 { name: "request", type: "OrderRequest" }
 ```
 
-类型本身不被编译成独立的数据结构——它们就是 TypeScript，被 `svp check` 用来做连线类型匹配。
+类型本身不被编译成独立的数据结构——它们就是 TypeScript，被 `forge check` 用来做连线类型匹配。
 
 ## 编译缓存
 

docs/design-rationale.md

@@ -172,11 +172,11 @@ TypeScript interface 在这里的角色不是"实现语言"，而是**对 AI 最
 
 ### 结构化的边界：拓扑骨架 vs 黑盒内部
 
-"AI 不需要结构化"不意味着什么都不结构化。SVP 的工具链（`svp check`、渲染器）需要程序化处理一部分数据。
+"AI 不需要结构化"不意味着什么都不结构化。SVP 的工具链（`forge check`、渲染器）需要程序化处理一部分数据。
 
 区分标准很简单：**层间的连接关系必须结构化，block 内部可以是黑盒。**
 
-需要结构化（`svp check` 要校验）：
+需要结构化（`forge check` 要校验）：
 - **pins 的类型** — 连线两端类型是否兼容
 - **wire 的引用** — from/to 指向的 pin 是否存在
 - **层间引用** — L4 step 引用的 L3 block 是否存在、签名是否匹配
@@ -201,7 +201,7 @@ SVP 协议（语言无关）
   └── 变更传播的机制
 
 SVP 工具链（某种语言实现）
-  ├── 校验器（svp check）
+  ├── 校验器（forge check）
   ├── 编辑器（svp-blueprint 等）
   ├── Skills（给 AI 编码工具的结构化 context）
   └── Store（.svp/ 数据读写）

docs/design.md

@@ -193,7 +193,7 @@ wires:
 
 ## 蓝图查看器
 
-`svp blueprint` 命令是 svp-blueprint 的只读可视化入口——读取 `.svp/` 下已编译的 L3/L4 JSON，生成自包含 HTML 节点图在浏览器中查看。
+`forge blueprint` 命令是 svp-blueprint 的只读可视化入口——读取 `.svp/` 下已编译的 L3/L4 JSON，生成自包含 HTML 节点图在浏览器中查看。
 
 设计要点：
 
@@ -204,7 +204,7 @@ wires:
 - **三种 L4 变体**：Flow（主要，节点图）、EventGraph（事件处理器列表）、StateMachine（状态节点 + 转换边）
 - **零依赖自包含**：单个 HTML 文件内联所有 CSS/JS/数据，无需服务器，离线可用
 
-查看器不做编辑——编辑仍然通过 YAML 文件 + `svp compile-blueprint` 完成。查看器是数据的一种只读渲染视图。
+查看器不做编辑——编辑仍然通过 YAML 文件 + `forge compile-blueprint` 完成。查看器是数据的一种只读渲染视图。
 
 ## 不做什么
 

docs/interaction.md

@@ -13,24 +13,24 @@ AI 编码工具（Claude Code、Cursor 等）天然围绕文件树 + 文件操
 
 ## 虚拟文件树
 
-`svp view` 命令把 `.svp/` 下的 JSON 数据实时渲染成 AI 友好的视图。不是真实文件，是按需计算的。
+`forge view` 命令把 `.svp/` 下的 JSON 数据实时渲染成 AI 友好的视图。不是真实文件，是按需计算的。
 
 ```
-svp view l5               # L5 overview
-svp view l4               # 所有 flow 的 overview
-svp view l4/create-order  # 某个 flow 的 detail
-svp view l3               # 所有 block 的 overview
-svp view l3/validate-order # 某个 block 的 detail
-svp view l2               # 所有 code block 的 overview
-svp view l1               # 源文件树（映射到真实文件系统）
+forge view l5               # L5 overview
+forge view l4               # 所有 flow 的 overview
+forge view l4/create-order  # 某个 flow 的 detail
+forge view l3               # 所有 block 的 overview
+forge view l3/validate-order # 某个 block 的 detail
+forge view l2               # 所有 code block 的 overview
+forge view l1               # 源文件树（映射到真实文件系统）
 ```
 
 ### Overview 视图
 
 每个实体在 overview 里只占一行——名字 + 签名 + 摘要统计。AI 看到全局拓扑，不被细节淹没。
 
 ```
-# svp view l3
+# forge view l3
 
 L3 Logic Blocks (7 blocks)
 ──────────────────────────
@@ -46,7 +46,7 @@ reserve-inventory (Reservation) → ReserveConfirmation
 ```
 
 ```
-# svp view l4
+# forge view l4
 
 L4 Logic Chains (2 flows)
 ─────────────────────────
@@ -62,7 +62,7 @@ cancel-order  POST /api/orders/:id/cancel
 展示该层的完整信息，但不自动展开其他层。用 `↑` `↓` 标注关联层，AI 知道往哪切换但不自动加载。
 
 ```
-# svp view l3/validate-order
+# forge view l3/validate-order
 
 validate-order
 ══════════════
@@ -93,7 +93,7 @@ description:
 ```
 
 ```
-# svp view l4/create-order
+# forge view l4/create-order
 
 create-order
 ════════════
@@ -155,9 +155,9 @@ dataFlows:
 用户（在 L4）："create-order 流程里，validate 之后加一个限流步骤"
 
 主 Agent（L4 层，上下文极少）：
-  1. svp view l4/create-order   ← 看当前流程
-  2. svp edit l4/create-order   ← 在 validate-order 后加 rate-limit 步骤
-  3. svp compile-plan           ← SVP 计算变更范围
+  1. forge view l4/create-order   ← 看当前流程
+  2. forge edit l4/create-order   ← 在 validate-order 后加 rate-limit 步骤
+  3. forge compile-plan           ← SVP 计算变更范围
 
 SVP 输出编译计划：
   - [新建] L3/rate-limit       ← 需要定义契约盒
@@ -179,9 +179,9 @@ SVP 输出编译计划：
 用户（在 L3）："validate-order 的 email 改成可选"
 
 主 Agent（L3 层）：
-  1. svp view l3/validate-order  ← 看当前契约
-  2. svp edit l3/validate-order  ← 删掉 email 的 required
-  3. svp compile-plan            ← SVP 计算变更范围
+  1. forge view l3/validate-order  ← 看当前契约
+  2. forge edit l3/validate-order  ← 删掉 email 的 required
+  3. forge compile-plan            ← SVP 计算变更范围
 
 SVP 输出编译计划：
   - [更新] L2/validate-order    ← sourceHash 不匹配，需要重编译
@@ -202,11 +202,11 @@ SVP 检测到 L1 变化：
   - L2/validate-order 的 contentHash 和 L1 实际哈希不匹配
   - 标记 drift（对账警告）
 
-用户跑 svp check：
+用户跑 forge check：
   WARNING [SOURCE_DRIFT] l2/validate-order: contentHash 不匹配，L1 被手动修改
 
 用户决定：
-  a. 接受 L1 的改动 → svp accept l2/validate-order → 更新 contentHash
+  a. 接受 L1 的改动 → forge accept l2/validate-order → 更新 contentHash
   b. 回退 L1 → 从 L3 重新编译覆盖
   c. 同时更新 L3 契约 → 手动修改后重新编译
 ```
@@ -245,21 +245,21 @@ L1（代码层）：    ~200+ 行/block ← 最重，但隔离在 subagent 里
 SVP 逐层渗透：
   用户说"加个限流" → 主 Agent 只看 L4 拓扑（20 行）→ subagent 各自处理
   上下文：每个 agent 最多几十行
-  风险：每层都有 svp check 校验，问题逐层可见
+  风险：每层都有 forge check 校验，问题逐层可见
 ```
 
 ---
 
-## 编译计划：svp compile-plan
+## 编译计划：forge compile-plan
 
-用户或 AI 修改了某层数据后，`svp compile-plan` 计算需要重编译的范围。
+用户或 AI 修改了某层数据后，`forge compile-plan` 计算需要重编译的范围。
 
 输入：当前层的变更（哪些实体的 contentHash 变了）。
 
 输出：结构化的任务清单，每个任务是一个独立的编译单元。
 
 ```
-# svp compile-plan 的输出示例
+# forge compile-plan 的输出示例
 
 Compile Plan (3 tasks)
 ──────────────────────
@@ -288,12 +288,12 @@ AI 编码工具根据这个计划派发 subagent。无依赖的任务可以并
 
 ---
 
-## 与 svp check 的关系
+## 与 forge check 的关系
 
-`svp check` 是编译后的验收工具。
+`forge check` 是编译后的验收工具。
 
 ```
-用户改 L4 → AI 逐层编译 → svp check
+用户改 L4 → AI 逐层编译 → forge check
                               │
                   ┌────────────┼────────────┐
                   ▼            ▼            ▼
@@ -306,7 +306,7 @@ AI 编码工具根据这个计划派发 subagent。无依赖的任务可以并
 check 报什么层有问题，用户就去那层看。这是逐层渗透模型的**闭环**：
 
 ```
-用户改上层 → AI 向下编译 → svp check 校验 → 有问题回到对应层修 → 再次向下编译
+用户改上层 → AI 向下编译 → forge check 校验 → 有问题回到对应层修 → 再次向下编译
 ```
 
 ---

docs/node-spec.md

@@ -27,7 +27,7 @@ AI 是编译器，不是 parser。`"request.items: array, min 1, max 50"` 这种
 
 ### 结构化的边界
 
-层间连接关系（pins 类型、wire 引用）需要结构化，`svp check` 要校验。block 内部（validate、constraints、description）是黑盒，工具只需展示，不需解析。
+层间连接关系（pins 类型、wire 引用）需要结构化，`forge check` 要校验。block 内部（validate、constraints、description）是黑盒，工具只需展示，不需解析。
 
 ---
 
@@ -312,7 +312,7 @@ graphs/
 
 ### 加载行为
 
-- `svp prompt compile/recompile/review` 时自动加载并注入 prompt
+- `forge prompt compile/recompile/review` 时自动加载并注入 prompt
 - subagent 只拉自己需要的 docs，不加载全量
 - 不影响 `contentHash` 计算——docs 是编译辅助信息，不是契约的一部分