mcpField
P
perimeter

perimeter

github.com/venhdev测试与质量1125 次安装1 天前更新
代码仓库

关于 perimeter

perimeter 是供开发者审查代码库架构边界的技能。它依据现有内部规范和实际绕行调用，并按具体故障风险筛选问题。

主要功能

  1. 01审计绕过封装的原始 API 调用
  2. 02追踪分层与依赖方向
  3. 03检查资源与沙箱规范
  4. 04按证据和风险筛选发现
  5. 05生成带代码位置的报告

适用场景

  1. 01查找绕过规范封装的调用
  2. 02发现跨层导入
  3. 03审查文件系统与资源处理
  4. 04确定架构边界风险优先级

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/venhdev/zenforge --skill perimeter

安装后在 Claude Code 中输入/perimeter确认已加载。

附带文件references/fitness-functions.md

详细介绍

perimeter — 架构边界与绕过检测引擎

领域准则

1. 边界审计维度
  • 已批准的基本构件与原始绕过（横向）：识别管理 I/O、网络客户端、资源或生命周期的内部封装；标记绕过这些封装、直接调用原始运行时 API 的调用点。
  • 层级与依赖方向（纵向）：追踪跨越架构层（Domain、App、Infra、UI）的导入图；标记方向反转或跨边界导入。
  • 资源与沙箱卫生：审计存储路径、并发池和内存缓冲区；标记未锚定的文件系统访问或未限流的资源。
  • 微型示例： 
    Banned:   fetch("https://api.domain/orders") // Raw runtime bypass
Required: appHttpClient.get("/orders")       // Sanctioned primitive with auth & telemetry
2. 承重约束资格门槛

严格按照以下 3 个条件筛选候选约束：

  1. 已存在的批准基本构件：代码库定义了用于处理该边界的内部封装、基类或规范路径。
  2. 有实证的绕过行为：至少有一个活跃调用点违反边界，直接调用原始 API。
  3. 可量化的失败风险：绕过会导致架构漂移、资源泄漏、内存耗尽或安全风险。
  • 边界之外：约束严格限定于已有内部基本构件支撑的承重架构边界；绝不审查表面风格、标准实用方法（Math.*、集合）或缺乏活跃封装的推测性规则。

规范输出约定

# Perimeter Report: <Target Subsystem / Scope>

## 1. Executive Verdict
- **Target Inspected**: `<directory_or_package>`
- **Verdict**: <HARDENED | PARTIAL | UNPROTECTED> (<N> active boundaries)
- **Primary Risk**: <Single-sentence technical judgment on highest boundary exposure>

## 2. Qualified Boundary Declarations
*(If HARDENED: 'All architectural boundaries are enforced by active test suites; zero raw bypasses detected.')*

### Boundary: <Constraint Name, e.g., Direct Network Client Bypass>
- **Offending Evidence**: [<file>#L<N>](file:///path/to/file#L<N>) ── <Bypass snippet or call site>
- **Failure Risk**: <Concrete risk: memory leak / auth bypass / architectural drift>
- **Rule**: Required: `<Sanctioned Primitive>` ── Banned: `<Forbidden Raw API>`
- **Enforcement**: Tier: `<Arch Unit Test | AST Linter | Script Guard>` | Whitelist: `<Exempt files | 'None'>`

## 3. Disqualified Invariants (Pruned) *(omit if no candidate patterns pruned)*
- **[PRUNED] <Candidate Pattern>**: <Reason for rejection, e.g., No existing codebase primitive / Trivial style issue>
路由
  • 符合条件的边界需要具体实施计划 →（通过 /changeset）。
  • 边界测试已有基于证据的 changeset，且执行范围已获授权 →（通过 /forge）。
  • 边界归属、白名单例外或架构权衡需要人工审议 →（通过 /clarify）。

执行协议

阶段 1：宏观锚点奠基
  1. 接收目标目录或子系统。
  2. 查找架构锚点（内部封装、批准的客户端、解析器、基础接口），以此奠定边界基准。
阶段 2：自适应规模的边界审计
  • 当前轮次内执行（少于 10 个文件或局部模块）：在当前轮次中，直接根据已发现的锚点审计调用点。
  • 子 Agent 扇出（大型代码库或跨层范围）：根据划分的切片或调用方声明的预算，动态扩展并发 research 子 Agent（角色：Perimeter Reviewer (<Slice>)），并为其提供目标切片目录、已发现的架构锚点、承重约束资格门槛、references/fitness-functions.md 的路径，以及要求提供问题代码定位信息（file:///...#L<N>）的规范子报告约定。
阶段 3：规范化与轮次终止门槛（汇总）
  1. 将调查结果整理为规范输出约定；将缺乏依据的规则移至第 3 节（已剔除；如果没有则省略第 3 节）。
  2. 如果边界归属或白名单豁免存在尚未解决的权衡：停止并进行审议（通过 /clarify）。
  3. 将报告输出到对话流中，并立即结束当前轮次。

评论

支持 Markdown