zrk222/code-factory

# 代码工厂 [](https://github.com/zrk222/code-factory/actions/workflows/ci.yml) [](https://pypi.org/project/factoryline-code-factory/) [](https://pypi.org/project/factoryline-code-factory/)  ## 60秒首次运行 使用 Code Factory 创建一个具备应用雏形的初始状态，然后立即查看 在没有真实测试的情况下，它拒绝认证哪些需求： ``` pip install factoryline-code-factory==0.10.6 factory app from-prompt "Build a simple approval tracker with an audit log" --out approval-tracker --purpose saas factory coverage --root approval-tracker --json ``` 最后一条命令在全新的启动模板上会故意以非零状态退出。对于每一个 缺少非空测试的产品需求，它会报告 `"dominant_failure_class": "hollow_coverage"`。脚手架是有用的初始状态，而 不是工厂假装准备好可以发布的 软件。 对于现有的代码仓库，请从 `forge adopt --root .` 开始；参见 [在现有代码仓库上的首次使用](docs/FIRST_USE.md)。 ## 证明优先架构 运行不带任何参数的 `factory`，即可获得已安装 brick、本地证明计数以及下一个有效命令的精简实时视图。这种 agent 优先的主视图避免了单独的 help/discovery 轮次，同时在所有地方保留了 `--help` 的可用性。 ``` flowchart LR A["Intent / PRD"] --> B["Real build + gates"] A --> C["Proof-by-sabotage challenges"] C --> S["Spec mutations"] C --> F["Empty stubs"] C --> H["Decision-rule mutations"] C --> D["Hidden or broken UI"] C --> I["Trace tampering"] B --> P["Factory Passport"] S --> P F --> P H --> P D --> P I --> P P --> G["GitHub summary + badge + Mermaid + attestations"] ```  **像乐高一样构建的代码工厂。** 五个独立的开源小组件 拼接成一条流水线：用自然语言描述一个功能，流水线 会检查其歧义，构建它，运行一系列门禁关卡，真正地 *运行* 完成的代码以观察其行为，将所有决策逻辑编译为永久的 零成本代码，然后发布它——每一步都带有凭证。 每个组件都是一个独立的代码仓库，你可以单独安装和使用。本仓库是 **底板** (`factory`)，负责将它们对齐组合起来。它不依赖于它们中的任何一个。 ## 五个 brick 的工作流 ``` flowchart LR A["Plain-language intent"] --> B["1 SpecLine: clarify and lock the spec"] B --> C["2 ForgeLine: build through gated phases"] C --> D{"What changed?"} D -->|"Business decision logic"| E["3 HSF: compile deterministic artifact"] D -->|"User-facing UI"| F["4 Prestige: design-quality gate"] E --> G["Receipts and signed artifacts"] F --> G C --> G G --> H["Ship with evidence"] ``` 像使用乐高积木一样使用这些编号的仓库：从底板开始，当意图模糊时添加 spec brick，当你想要状态机时添加 forge brick，当决策必须具有确定性时添加 compile brick，当发布的产品带有用户界面时添加 design brick。 ``` intent -> [1-spec] -> spec + strict contract -> handoff | [2-forge] <---- tasks / plan <----------+ | architect -> build -> gates -> smoke -> ship |-> if UI -> [4-design] design-quality gate +-> if decision table -> [3-compile] -> deterministic artifact ``` ## 五个组件 | 仓库 | pip install | CLI | 功能 | |---|---|---|---| | **code-factory** (本仓库) | `factoryline-code-factory` | `factory` | 底板——将各个 brick 拼接在一起，计量成本 | | **code-factory-1-spec** | `code-factory-1-spec` | `specline` | 在 AI 编写代码 *之前* 消除歧义（防漂移输入契约） | | **code-factory-2-forge** | `code-factory-2-forge` | `forge` | 流水线：架构设计 -> 构建 -> 门禁 -> **runtime 冒烟测试** -> 发布 | | **code-factory-3-compile** | `code-factory-3-compile` | `hsf` | 将决策 *一次性* 编译为能以零 AI 成本永远运行的枯燥代码 | | **code-factory-4-design** | `code-factory-4-design` | `prestige` | 设计质量门禁，适用于发布产品带有界面的情况 | 使用数字编号，以便能一目了然地读取组装顺序。你可以安装一个、几个或全部。 底板的 PyPI 发行版命名为 `factoryline-code-factory`，因为 PyPI 保留了更通用的 `code-factory` 名称。仓库和 `factory` 命令特意保留了更简单的 Code Factory 标识。 ## 企业知识激活 Code Factory 将 agent 指令视为 **原子知识单元 (AKU)**： 机构知识的微小、高密度、经过验证的单元。其目标是 从“检索长篇文档并指望 agent 理解它”转变为“在确切的执行步骤中激活 正确的流程、工具、治理和验证器。” 企业 schema 以及每个 brick 如何映射到编撰、压缩、注入和验证，请参见 [AKU_STANDARD.md](AKU_STANDARD.md)。 ## 安装所有五个 brick ``` pip install factoryline-code-factory==0.10.6 code-factory-1-spec==0.5.1 code-factory-2-forge==0.10.2 code-factory-3-compile==0.5.2 code-factory-4-design==0.7.1 ``` ## 身份签名凭证 使用 Sigstore 的无密钥 OIDC 流程对任何现有的 factory 凭证进行身份验证： ``` pip install "factoryline-code-factory[sigstore]" factory receipt sign .factory/receipts/.json factory receipt verify .factory/receipts/.json \ --cert-identity "https://github.com/OWNER/REPO/.github/workflows/WORKFLOW.yml@refs/heads/main" \ --cert-oidc-issuer "https://token.actions.githubusercontent.com" ``` 验证将确切的凭证字节与预期的签名者身份和 签发者绑定。未签名的凭证仍然可读，但报告为 `UNSIGNED`，绝对不会 显示为 `VERIFIED`。有关 CI 工作流、预期的 JSON、失败行为和诚实的边界范围，请参见 [已签名的 Factory 凭证](docs/SIGNED_RECEIPTS.md)。 ## 本地控制平面基础 控制平面接口增加了租户范围内的证据、明确的角色 授权、独立的人工批准以及哈希链接的审计流： ``` factory control init --db .factory/control.sqlite3 factory control evidence-put receipts/build.json --db .factory/control.sqlite3 ` --tenant acme --subject ci-runner --roles operator factory control audit-verify --db .factory/control.sqlite3 ` --tenant acme --subject auditor --roles viewer ``` 有关批准工作流 和确切边界，请参见 [docs/CONTROL_PLANE.md](docs/CONTROL_PLANE.md)。这是未来托管 SCM、SSO/SCIM 和证据存储适配器的确定性本地基础；它并不 声称自己是一个托管的多租户服务。 ## 企业凭证 v2 基础 可选的企业扩展增加了一个可通过离线验证的 DSSE 信封，包含 Ed25519 签名者身份、已签名的策略包和已签名的吊销列表： ``` pip install "factoryline-code-factory[enterprise]" factory enterprise keygen --out-dir .factory/keys --keyid ci-main \ --identity "https://github.com/OWNER/REPO/.github/workflows/proof.yml@refs/heads/main" \ --issuer "https://token.actions.githubusercontent.com" factory enterprise receipt-seal receipt-v2.json \ --private-key .factory/keys/ci-main.private.pem --keyid ci-main \ --identity "https://github.com/OWNER/REPO/.github/workflows/proof.yml@refs/heads/main" \ --issuer "https://token.actions.githubusercontent.com" --out receipt.dsse.json factory enterprise verify receipt.dsse.json --trust-root .factory/keys/trust-root.json ``` 验证是在本地进行的，并且默认失败关闭。它会检查 DSSE 签名、确切的 payload 摘要、受信任的密钥 ID、身份、签发者、策略摘要和提供的 吊销列表，而无需联系服务。v1 凭证仍然可读，但在企业验证器中会返回 `LEGACY_UNVERIFIED`。本地控制平面 基础已在上面说明；托管的 SCM/SSO 适配器、OSCAL 包、BBS 凭证和 zkVM 证明仍是未来的路线图工作；请参见 [企业 凭证 v2](docs/ENTERPRISE_RECEIPTS.md)。 ## 现有代码仓库和 PR 使用 `forge adopt --root .` 从继承的代码开始。它会写入 一个可审查的架构基线，并且对于 TypeScript，会为 `forge verify-tests-ts` 提供明确的变异清单。FactoryLine 公开了专业人士所需的操作 控制：`factory overhead` 报告每个门禁测得的执行时间（wall time），`factory override` 写入受控的异常凭证，并且 `factory ci init --feature ` 会写入一个可选的 GitHub PR 评论工作流。 ``` factory doctor --strict # versions + required command compatibility factory plan # print the assembly pipeline factory init . # lay down the shared workspace factory assemble my_feature # run the line (skips any missing brick) factory meter # receipted cost + savings, computed on YOUR runs factory rollup my_feature # aggregate receipt attribution for debugging factory trace my_feature # hash-link receipts into a proof bundle factory verify-trace .factory/traces/my_feature.trace.json factory replay .factory/traces/my_feature.trace.json --changed smoke/my_feature.json factory evidence my_feature # public-safe proof for a PR or release note factory policy # write default policy-as-code thresholds factory verify-policy --challenge policy.challenge.json # prove every policy rule is enforced factory optimize-pr --changed specs/my_feature.md --feature my_feature factory pr-pack my_feature # reviewer-ready PR_EVIDENCE.md factory app from-prd PRD.md --out my-app --purpose saas factory challenge my_feature --trace .factory/traces/my_feature.trace.json factory passport my_feature --trace .factory/traces/my_feature.trace.json --challenge .factory/challenges/factoryline.json ``` `factory assemble` 是可恢复的，并在人工负责的创作和批准 边界处停止。其 JSON 输出会明确指出 `paused_at` 和确切的 `next_command`；它 不会静默批准架构，也不会声称未完成的脚手架已构建完成。 有关现有代码仓库的简洁路径和首次运行的反馈路线，请参见 [在现有代码仓库上的首次使用](docs/FIRST_USE.md)。现在最好的贡献 是真实的代码仓库运行，包括工作流在哪里起到了帮助或在何处失败。 有关所有五个挑战 命令和生成的 Mermaid artifact，请参见 [ProofLab 和 Factory 护照](docs/PROOFLAB.md)。 有关发布顺序、GitHub release 步骤、Claude Code/Codex 设置和 发布链接，请参见 [PUBLICATION_GUIDE.md](PUBLICATION_GUIDE.md)。 ## 即时 PRD 转应用构建器 `factory app` 是一个一次性应用构建器工作流：输入 PRD 或 prompt， 输出全栈启动模板，并附带已附加的门禁和证据钩子。 将输出结果视为具有应用雏形的初始状态，在发布前 仍需经过 SpecLine、ForgeLine、HSF、Prestige 和 Factoryline 验证。 ``` factory app from-prompt "Build an expense approval app with manager review, audit logs, and policy-based approvals" --out expense-approval factory app from-prd PRD.md --stack nextjs-fastapi-postgres --purpose healthcare --out prior-auth-portal ``` 它会生成 `app_blueprint.json`、`PRD.md`、前端/后端/数据库启动文件、 冒烟测试和工作流指南。关键不在于绕过工程 判断；关键在于让第一个具备应用雏形的仓库瞬间出现，同时 保留工厂契约。 有关可视化工作流、 示意性就绪模型、生成的文件树和后续命令，请参见 [docs/APP_BUILDER.md](docs/APP_BUILDER.md)。 ## PR 优化控制平面 高级审查现在是一个 factory 接口。`factory optimize-pr` 将 diff 转化为 一个有边界的加固计划：更改的路径、失效的门禁、设计/发布 检查、终态以及禁止自动合并的权限边界。它是 确定性的，可以在打开或更新 PR 之前安全地运行。 `factory pr-pack ` 从哈希链接的追踪记录中写入一个对公众安全的审查包：更改了什么、哪些凭证证明了它、计量表可以 诚实地测量什么，以及哪些声明仍在范围内。`factory policy` 使 团队规则保持可见：空洞测试证明、空洞验证器证明、发布 就绪情况、设计目的和批准边界。 `factory verify-policy --challenge policy.challenge.json` 完成了相同的 针对策略规则的变异准则：它会删除或反转每一条规则，并要求 你的评估器拒绝被更改的策略。存留下来的规则会被报告为 `HOLLOW_POLICY`；请参见 [验证策略](docs/VERIFY_POLICY.md)。  ## 为什么是乐高，而不是单体架构 - **每个 brick 独立存在。** 只安装你需要的；缺少的 brick 会被跳过，而不是致命错误。 - **文件系统互操作 = 最大可移植性。** Brick 在共享的 布局下通过磁盘传递工作。任何能够运行 子进程的 IDE、agent (Codex / Claude Code / Cursor)、CI 运行器或 OS 都可以驱动工厂。没有 daemon，没有网络，没有锁定。 - **没有隐藏的耦合。** 底板不依赖于任何 brick——它通过 shell 调用 它们的 CLI。独立地升级或替换某个 brick。 ## 诚实的计量 `factory meter` 让“节省时间和金钱”的主张成为 *你自己的*，这是根据你的运行情况计算出来的： - 在 **没有测量的运行记录** 时，它拒绝打印节省百分比——在零数据面前不提供数字。 - 当模块不报告 token 使用情况时，它会将该数据标记为 **model（模型）**，而不是 measurement（测量结果），并如实说明。 - 它会内联打印 **基准假设**，因此没有任何数字会隐藏其对比依据。 挂钟时间总是被测量的。预测总是会被标记。没有任何东西是捏造的。 ## 发布测量 使用 [`scripts/capture_launch_metrics.ps1`](scripts/capture_launch_metrics.ps1) 将原始的 PyPI 和 GitHub 流量观察结果保存为 JSON 凭证。它记录了 下载量、浏览量和克隆量，但不会将它们中的任何一个称为独立用户或 归因转化；请参见 [发布测量](docs/LAUNCH_MEASUREMENT.md)。 ## 携带证明的 PR `factory trace ` 会写入 `.factory/traces/.trace.json`：这是一个 基于该功能最新兼容凭证的确定性证明包。 每个追踪节点都记录了阶段、命令、凭证哈希、声明的 artifact 哈希、前一个节点的哈希以及归属摘要。链首节点使得凭证或 artifact 的篡改变得可见。 `factory rollup ` 是用于 调试失败阶段的较低级别凭证归属视图；`factory evidence ` 是用于 PR、发布说明和 README 声明的公众安全视图。 ``` factory trace checkout_flow factory verify-trace .factory/traces/checkout_flow.trace.json factory rollup checkout_flow factory risk-diff --changed smoke/checkout_flow.json factory replay .factory/traces/checkout_flow.trace.json --changed smoke/checkout_flow.json factory replay .factory/traces/checkout_flow.trace.json --changed smoke/checkout_flow.json --execute factory attest .factory/traces/checkout_flow.trace.json factory evidence checkout_flow ``` 这是企业级的乐高层：工厂可以说出一个更改 使哪个保证失效了，哪些最低限度的阶段必须重新运行，追踪是否仍然通过验证， 以及在不泄漏原始日志的情况下可以展示哪些公开证据。如果冒烟测试 是无效的（hollow），公开证据会显示 `hollow_test`；如果追踪被篡改 过，`verify-trace` 会在任何人信任该 PR 之前失败。对于希望将供应链 证据附加在 PR、release 或 wheel 旁边的团队，`factory attest` 会导出 未签名的 in-toto/SLSA 格式的 JSON 语句。 ## Spec 验证器变异 流水线现在会验证 spec 工具本身： ``` specline strict checkout_flow --json specline verify-validators checkout_flow --json ``` `verify-validators` 会一次删除或反转一个需求，并要求 严格的 lint 来杀死变异体。如果变异体仍然通过验证，则会报告该需求为 `hollow_validator`：spec 看起来是有效的，但没有验证器证明该 需求是有意义的。在默认的 factory 链中，这运行在 `specline:strict` 之后，并在 spec 门禁签发或下游构建阶段之前。 ## 跨平台 底板运行在 Python 3.10-3.12 上。四个带编号的 brick 运行在 Python 3.11-3.12 上。它们的 CI 矩阵涵盖 Ubuntu、Windows 和 macOS。 ## 许可证 MIT OR Apache-2.0。免费且开源。每个 brick 都包含这两种许可证文本。 提供商业支持和集成服务——请参见 [SUPPORT.md](SUPPORT.md)。

标签：AI辅助编程, Python, 无后门, 测试用例, 软件工厂, 逆向工具