code-factory

Code Factory

Agent 已向你提交一项更改。现在，你需要决定是否接受。 Code Factory 将发现项、源代码上下文和已记录的检查整合到一条审查记录中。检查发现项，选择修复方案，然后重新运行受影响的检查。 你可以将证据与更改一并留存，并由你自己作出决定。 从一条命令开始：

python -m pip install factoryline-code-factory
factory scan --root .

你的工作流： 扫描 → 审查发现项 → 修复 → 运行测试并再次执行受影响的检查。基础扫描会读取符合条件的 Python 源代码；不会运行你的项目。证据缺失表示不完整，而非一切正常。

Python 源文件预算默认为 2,000 个。factory scan --max-files 1000 可为单次运行设置较小的预算；超出预算时，扫描会明确停止，不会悄悄跳过文件。此运行时预算与 CF 自身的架构上限相互独立。人类可读的输出包含发现项的位置，以及已审计／已发现的源代码数量。 退出码 0 表示没有阻塞性发现项或失败的检查；仍可能存在建议项和缺失的证据。退出码 2 表示分析受阻或无效。Python 静态检查结果干净，并不能证明运行时覆盖情况或获得发布批准。 使用 --static-only 仅执行 Python 路径；默认情况下还会协调其他适用的证据通道。JavaScript、shell 和其他语言的审计需要外部工作器。

当前源代码预览 — core 0.49.0、VS Code 1.3.0、JetBrains 1.3.0

有范围限制的安全审查会沿着受支持的本地辅助函数追踪值，直到 HTTP、文件和 SQL 接收点，并单独检查上传目录与其净化后的文件名。Studio 会提供统一的下一步操作；可选的 JEV 集成仍仅供参考；无法执行的评估会保持为不完整。这些更改并不代表已实现穷尽式分析，也不代表检测准确率已经过测量。在使用修复方案之前，请先审查发现项、运行受影响的检查，并决定是否接受。

想要图形化工作区？运行 factory studio --root .。需要查看选项？ factory --help 可显示简要用法；factory --help-all 可显示所有命令。 从快速指南开始。

请保留 pytest、变异测试、CodeQL、Semgrep 和你的审查清单。CF 会在此基础上补充测试质量发现项和基于源代码的本地证据。基础扫描无需复杂的接入流程、签名密钥、租户设置或 Docker。原生工作器的执行需要单独配置，并遵守相应的安全要求。

Code Factory 是产品。其内部引擎和高级治理功能都是可选工作流，并非审查代码的前提。

从一个想法开始？

向你的编码 Agent 描述想法，并创建 PRD.md。可选的入门指南可帮助你将想法转化为具体的验收检查。 如果是现有代码库，请从上面的扫描开始。

从一个想法到可审查的变更

如果你是新手构建者，可以从一个想法开始，明确预期行为。 如果你是经验丰富的开发者，可以从仓库或拟议的差异开始。 SpecLine 帮助梳理需求；ForgeLine 增加架构和测试意图检查；Code Factory 将发现、证据和后续操作串联起来。基础扫描不需要这些可选工作流。

然后检查发现的问题，修复代码，并重新运行受影响的检查。继续使用你的编码 Agent 和审查服务，包括 CodeRabbit、Devin 或 Blitzy。 CF 增加了测试意图检查、可选的运行时变异证据，以及与源代码绑定的本地收据。审查服务也提供测试和分析；CF 的证据可帮助你与这些服务配合检查工作。

**演示，2026 年 10 月 16 日：**已安装的本地 CF 运行时扫描了一个虚构的 Python 文件，并报告了两项预先植入的安全问题。Studio 显示已评估 1/1 个源文件，且证据不完整。这些是实际示例运行的观察结果，并非准确性基准测试、JetBrains IDE 截图或发布批准。尚未运行的运行时检测仍会显示为未运行。

在你自己的仓库中试用免费的本地核心版本。如果觉得有帮助，可以给项目点一个 GitHub Star，让更多人发现它；也可以派生项目，改进规则，或贡献可复现的正例和反例。报告遗漏问题和误报同样是有价值的贡献。

Code Factory + ForgeLine（CF/FL）是一套稳健、本地优先的代码审计工厂。 它首先收集候选变更的本地软件审查证据。 它将需求、架构检查、Python AST 安全分析、行为测试证据、工作流完整性、专项 AI 审查和可执行的修复建议连接起来。它生成的收据可用于审查；该工具不会认证软件、保证不存在缺陷，也不会批准发布。

**产品命名：**Code Factory 是产品，ForgeLine 是其审计和架构引擎。只有项目声明了相应范围时，才会出现 SpecLine、HSF 和 Prestige 这些高级内部检测流程；新用户无需在扫描前学习独立产品。

Graph Ops 实战

这张本地全页截图展示了 Graph Ops 如何从已封存的谱系追踪变更，经过取证发现，直至提出恢复路径。受保护的操作仍处于锁定状态；该仪表板是只读检查界面。

反事实竞技场会对比修复候选项，并展示其证据和风险。优胜者控制项 和证据前沿 展示了审查者如何检查理由并选择下一项证明。

当前的 Graph Ops UI 还会分别展示原生深度扫描进度、已评估的深度审计收据、六条运行时通道和各个 JUnit 测试用例。每个面板都会标注其证据状态和下一步修复操作。筛选或搜索已记录的测试，然后按需加载更多用例；库存记录或缺失的报告绝不会显示为通过的运行。JUnit 读取器最多接受 10,000 个用例，并会将规模更大或格式错误的报告标记为不完整。JUnit 报告属于本地观察结果，未与当前候选项绑定。

这张本地 UI 截图展示了每个报告测试用例的状态。对于未绑定结果的检查，审计卡片会明确标记为未运行。

补充：带注释的实时 Assembly 遥测数据

这些标签解释了原始的本地 Assembly 截图。 图中所示的运行正在等待人工输入；这并不表示已获准发布，也不表示所有检查都已通过。

## 添加更深入的审计通道

factory scan --root . --deep

深度模式会统筹架构、Python 安全性与测试预言检查、工作流完整性、需求、运行时覆盖率和依赖证据。 它会明确盘点 TypeScript/JSX、Go、Rust、Java、C/C++、C#、Ruby、PHP 和 Swift 等语言；缺少原生分析的部分仍标记为未测量。

如需执行已获授权的原生分析，请使用：

factory scan --root . --deep --worker-config .factory/worker-config.json --json

配置包含相对于工作区的 manifest、authorization 和 trust_root 路径，以及 manifest_sha256 和 trust_root_sha256 校验值。 这会调用现有的签名 Docker 工作器引擎，执行已配置的 CodeQL、 Semgrep、机密信息、依赖、容器、运行时和模糊测试通道。未签名的计划 会被拒绝。工作器完成后，仍需由独立 Agent 审查； 证据缺失或未完成审查，都无法得出通过的判定。原生执行需要配置的镜像和工具， 耗时可能超过一分钟。每个未解决的通道都会列出后续操作。仅有收据并不代表 已完成验证，任何扫描都不声称能检测出所有缺陷。

自本次源代码更新起，软件包元数据将使用 Production/Stable。 该发布状态标签与检测准确性、独立基准测试结果和提供方发布情况无关。

在交互式终端中，factory 可选择进行一次普通的 PyPI 版本检查，并将结果缓存 最多 24 小时；若有更新版本，则会显示通知。它不会下载或安装更新。CI、JSON 输出、服务端/MCP、帮助、版本和非交互式运行中会静默跳过检查；设置 FACTORY_DISABLE_UPDATE_CHECK=1 可关闭检查。此可选请求不会包含项目路径、 账户标识符或使用数据。除非操作员明确使用单独的提供方集成，否则所有审计和证明命令 都仅在本地运行。

从正在审查的项目目录运行仓库命令。factory guide 只用于了解项目概况； 它不会运行测试或 Agent。

检查此仓库

这些命令会显示当前的架构策略、范围受限的静态安全扫描，以及运行时审计设置：

factory architecture health --root . --json
factory audit security --root . --json
factory runtime-audit status --root . --json

factory audit security 会检查有限的一组源代码模式。它不是 渗透测试。运行时审计需要单独审查的计划及其自身的环境证据。状态为 NOT_RUN 或静态扫描结果干净，都不代表已完成完整的项目审计。

如需在 Graph Ops 中显示单项测试，请使用 JUnit 报告运行测试套件，报告路径为 .factory/test-reports/pytest.xml（例如， python -m pytest --junitxml=.factory/test-reports/pytest.xml）。本地 Studio 会读取报告，并将候选绑定标记为 UNBOUND；它不会推断源代码变更后 这些结果仍然适用。

上一快照的仓库自审收据 记录了 A (97.9/100)，并将 1,055/1,085 个函数归因于测试意图 （97.24%）。该静态测量仅适用于其中记录的源代码摘要；对于此候选版本，它已由上方干净的受跟踪快照结果取代；它不代表运行时覆盖率或认证。

ForgeLine 0.10.8 会针对其记录的 metrics.scope.code_files 中的公共模块函数和公共类方法计算 Python 复杂度； 以下划线 _ 开头的名称不纳入计算。其 AST 指标会统计分支、布尔表达式中的备选项、异常处理器、with 和断言。Ruff C901 使用不同的 McCabe 指标，并且也会检查私有函数。因此，CI 会单独在上限为 10 的情况下运行 python -m ruff check --select C901 factoryline tests。 ForgeLine 的最大值不能视为所有 Python 函数的最大复杂度。 CI 还会检查 action 和可复用工作流引用是否固定到不可变的提交；通用工作流证据验证器本身不会检查这些引用。

发布控制

候选版本预检要求通过发布节奏准入，并满足严格的架构健康要求。受保护的 main 分支要求通过 CI 和单独的专业 AI 源码审查；协调器会记录该评估，并将其与测试证据分开。这不是第二次人工审批。提供商发布和市场审批是不同的结果。请参阅发布渠道。

架构健康检查会核查增长预算。ForgeLine 的仓库清单和功能 QA 是分开的检查。当前差距审查记录了历史解析器行为；当前候选版本的固定解析器结果列于上文。CF 要求 ForgeLine 0.10.8，并在 factory doctor --strict 期间检查真实的 MJS、TS 和 TSX 功能 QA。静态信号既不代表已执行的覆盖率，也不构成安全认证。

更多详情

• 工程审查工作流
• GitHub 证明审查
• 商业可用性和限制
• 审计条件清单
• 运行时保障限制
• 发布渠道和发布证据
• 变更日志
• 文档索引

更新的视频预览

60 秒 CF/FL 审计与修复演示 — 2026 年 10 月 8 日。静音字幕、当前 Graph Ops 截图、范围受限的扫描器改进，以及 Agent 修复证据要求。源渲染文件位于 videos/code-factory-proof-of-survival/remotion。

原生 Agent 工具框架预览 — 当前源码候选版本

状态：仅为当前源码预览；已发布的 Code Factory 0.48.1 保持不变。不声称其已包含在本地 wheel 中。

原生工具框架会保留事件检查点以供恢复，将审查上下文分片绑定到源码，并在不应用候选修复的情况下对其进行比较。预算受限的 Jev 分诊会将尚未处理的事件显示为待处理，而非未评估。并行审计为可选项，且要求签署一项声明工作不会修改数据并保证资源安全的策略；串行审计仍为默认方式，而该声明并不能证明隔离性。可选的激活实验只会调用调用方明确注册的钩子。其实验观察结果不构成模型认证或准确性证据。源码分类体系和清单为 Junie 定义相同的路由，同时明确展示执行和身份方面的限制。

原生扫描器扩展 — core 0.49.0 / editor 1.3.0 源码预览

已修复： 原生扫描器控件要求易受攻击和安全结果与映像、配置文件及源代码哈希绑定。缺失的证据仍视为不完整。 测试意图审计现可识别参数/await 断言、预期异常失败检查，以及被调用的本地断言辅助函数。 测试中的直接本地序列化往返会保留信息性发现和自定义 reducer 警告。 已更改： Agent 使用一个 factory scan --deep 概览，以及根据项目语言和风险明确配置的原生工作器。 JavaScript/Actions 工作器会验证捆绑的已编译查询，而不是重新构建；收据发现会跳过对无关日志的显式文件检查。 新增： CodeQL JavaScript/TypeScript 跨过程分析、GitHub Actions security-extended 分析，以及十条包含本地污点跟踪的 Python/JavaScript/TypeScript Semgrep 规则。CodeQL 控件要求原生流程证据；Semgrep 社区版输出不能证明跨文件覆盖率。 外部来源回归语料库包含来自 requests、Rich 和 Click 的上游案例。这些源代码测试样本用于测试受支持的回归案例；运行时验证仍是一个单独步骤。

Code Factory 是一款强大的代码审计工厂，软件包元数据标记为 Production/Stable。此源码预览不能证明有新的市场发布、已对每个仓库进行运行时验证，或检测准确率经过测量。

更小的模型，更强大的质量工作流

CF/FL 旨在通过确定性工作流、独立审计和基于证据的修复，引导较小的大模型实现接近前沿水平的编码性能。 密封的任务包会明确列出需求、范围和验收检查。 这是设计目标；模型性能持平和节省成本需要通过配对基准测试来验证，当前的归因指标并未证明这一点。