OBLITERATUS 发布流程实战指南从 PR 审核到精确 Tag 认证的端到端质量门禁【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS导读本文围绕 docs/RELEASE_PROCESS.md 展开系统讲解 OBLITERATUS 项目如何将贡献者反馈、维护者验收、主线集成与发布认证四个环节彻底分离并以此构建机器可读策略驱动、精确 SHA 绑定、证据可独立核验的发布管线。读完本文你将掌握该项目的四阶段 PR 状态机、发布候选的完整准备步骤、v*精确 Tag 的发布认证门禁清单、确定性源码快照与 SBOM/SLSA 证据链的生成与核验方法以及条件化证据conditional evidence与豁免waiver在发布中的语义边界。OBLITERATUS 是面向大语言模型拒绝行为研究abliteration的开源工具包其发布流程贯穿研究可信度与软件供应链安全两条主线一条是仓库级覆盖率、变异测试分数、风险映射等质量门禁另一条是锁定依赖、确定性源码 ZIP、CycloneDX SBOM、SLSA 溯源与 Sigstore 签名组成的交付物证据链。两者共同决定了一次发布成立的最低事实标准。一、核心原则绿 PR 不是接受决定OBLITERATUS 发布流程的第一个设计原则在文档开头即被点明Pull-request check 通过是必要条件但它本身不构成接受acceptance或发布release决定。换句话说贡献者侧绿灯只是入场券。真正具有权威性的是两样东西被强制执行的工作流enforced workflows即 CI 中按机器可读策略实际运行的检查机器可读策略文件machine-readable policies即仓库中ci/目录下由 JSON 表达的、可被 CI 直接消费的门禁定义。文档本身只是向维护者解释如何应用这些策略而策略文件才是权威来源。这一设计让人维护者判断与机自动门禁各司其职机器保证事实下限维护者负责超出机器范围的审计判断。二、四阶段 PR 状态机发布流程将一次变更的生命周期严格划分为四个状态每个状态都有明确的准入/退出条件状态含义关键约束Reviewable可评审精确的 PR head 已签名、无冲突、贡献者侧检查全绿相关行为有聚焦的测试覆盖描述中明确列出未运行的测试、风险面与证据边界Accepted已接受维护者对不可变的 head SHA 完成审计审计覆盖正确性、研究诚信、安全、兼容性、文档及适用的策略/风险映射变更Integrated已集成已接受的 head 以仓库配置的 merge-commit 方式合入主线不使用 squash / rebase 合并生成的 canonicalmain提交必须具有 forge 验证签名合入后 CI 必须通过Release-certified已发布认证干净 canonical 提交上的精确签名v*tag 通过全部必需发布门禁产出的源码快照与证据已独立核验两个容易被忽略的细节新提交会使审计失效Accepted状态的审计绑定的是不可变的 head SHA。一旦 head 上出现新提交该审计即失效必须对新 head 重新检查。不接受 squash / rebase 合并Integrated状态严格要求使用仓库配置的 merge-commit 方法目的是让 canonicalmain的历史保持每次合并都可追溯到一个已审计 SHA的结构。此外文档允许维护者在接受前以独立署名、已签名的提交补充测试深度或加固hardening但明确禁止为了促成合并而削弱任何阈值、断言、必需任务或风险映射。源码佐证PR 快车道fast lane的策略表达快车道比发布套件更窄这一原则在 ci/pr-test-policy.json 中有量化表达变更行覆盖率下限为50%changed_line_coverage_floor: 50.0无论变更范围如何始终运行的测试always_tests包括tests/test_module_imports.py、tests/test_cli_boundaries.py、tests/test_runtime_contracts.py、tests/test_abliterate.py、tests/test_strategies.py基础设施路径.github/workflows/**、ci/**、pyproject.toml、uv.lock、scripts/check_*.py等触发对应的基础设施测试集如tests/test_ci_policy.py、tests/test_supply_chain_policy.py、tests/test_quality_policy.pytests/conditional/前缀的测试被明确排除在快车道之外——它们走的是 条件化测试文档 描述的独立门禁。[ci/test-quality-policy.json](https://link.gitcode.com/i/2fbaaf9850879f544fc485a16523de06)则定义了发布级的质量下限详见本文第四节两套阈值的分层正是快车道窄、发布套件宽的工程落地。三、接受标准什么情况下 PR 不能被接受文档用否定式清单定义了接受边界——满足以下任一条件即禁止接受被评审的 head SHA 与当前 head 不一致存在无法验证签名的提交必需检查处于 pending、failing、stale 状态或附着于其他 SHA相关行为没有有意义的测试或契约覆盖仍存在未解决的评审讨论、冲突、无法解释的生成文件、无关变更或未处理的信任边界风险研究/性能声明超出了所提供可复现证据的范围依赖、工作流、策略、文档或兼容性影响没有包含在同一可评审变更中。最后一条值得展开依赖、工作流、策略、文档或兼容性影响必须同变更一并评审。这与 ci/digests.txt 记录的依赖更新纪律一脉相承——工具固定与依赖升级不是可以悄悄附带在功能 PR 里的小事而是供应链政策的一部分。信任边界风险的工程含义[ci/test-risk-map.json](https://link.gitcode.com/i/0b4ab63acd566946b06deb4898f5d43c)是这一原则的机器化形式它将全部源码模块按cpu-contract、mixed-runtime、conditional-runtime三种风险类别分级并给每个模块绑定required_tests与conditional_gates。例如obliteratus/device.py属于mixed-runtime必需测试为tests/test_device_boundaries.py并挂接cuda-runtime、jetson-runtime、mps-runtime三个条件门禁obliteratus/models/loader.py同时挂接model-download-runtime、cuda-runtime、jetson-runtime、bitsandbytes-runtime四个门禁obliteratus/remote.py挂接remote-execution门禁。这意味着无法在标准 CI 中运行的环境绑定逻辑不再是评审盲区而是被显式登记为条件门禁的覆盖对象——这正是文档所说相关行为没有有意义的测试或契约覆盖时不得接受的具体落实。四、发布候选准备五步收口当所有已接受的工作合入后维护者进入发布候选release candidate准备流程共五步核对托管队列清理 pull-request 与 issue 队列确认没有悬而未决的变更清理与同步删除已合并分支确认main干净且已同步核验签名与 CI确认 canonical 合并签名有效、合入后 CI 全部通过运行就绪套件针对精确候选运行详尽的本地或托管就绪套件readiness suite版本与打签更新项目版本号创建新的签名标注标签signed annotated tag。其中针对精确候选运行不是套话——发布门禁全部绑定到v*tag 对应的具体提交而不是main 分支的最新状态。这也是第五步版本号 签名 tag必须在就绪套件通过之后执行的原因。Tag 不可变审计记录文档对失败候选的处理写得非常明确Tags are immutable audit records. A failed candidate is not moved, deleted, or reused.即tag 是不可变的审计记录。失败的候选不会被移动、删除或复用它保持未发布状态留在历史中修正后的候选使用新的补丁版本号和新的签名 tag。从供应链视角看docs/SUPPLY_CHAIN_POLICY.md 的表述失败的 tag 保留为不可变、未发布的审计记录修正候选使用新版本——发布编号是一次性的这保证了任何下载者都能精确对应哪一个提交的哪一次认证。五、精确 Tag 发布认证exact-tag workflow 门禁清单推送v*tag 会触发针对该 tag 提交的详尽发布工作流文档列举了四大类门禁1. 跨版本测试矩阵与覆盖率下限Python3.10 / 3.11 / 3.12三版本测试import / CLI 冒烟检查仓库与分支覆盖率下限repository and branch coverage floors关键文件下限critical-file floors成熟 CPU 作用域策略mature CPU-scope policy触及模块无回归对比touched-module no-regression comparison。这些阈值在 ci/test-quality-policy.json 中量化为指标下限仓库语句覆盖率repository_statement75.0%仓库分支覆盖率repository_branch60.0%变更行覆盖率changed_line50.0%成熟 CPU 作用域语句覆盖率mature_cpu_statement94.0%成熟 CPU 作用域分支覆盖率mature_cpu_branch84.0%变异测试分数mutation_score85.0%警告预算warning_budget0该策略还列出了 13 个关键 CPU 路径critical_cpu_paths包括obliteratus/runtime_contracts.py、obliteratus/models/loader.py、obliteratus/cli.py、obliteratus/telemetry.py等——这些文件承担运行时契约、加载边界、CLI 解析与遥测等对正确性最敏感的逻辑是发布认证的强制覆盖对象。成熟 CPU 作用域通过mature_cpu_scope.exclusions精确定义15 个必须真实模型运行时、外部服务、交互 UI 或远程/硬件执行才能覆盖的模块如obliteratus/abliterate.py、obliteratus/remote.py、obliteratus/local_ui.py被显式排除并逐条登记其conditional_gate——排除了却不登记门禁CI 就会失败。这是边界透明化而非放水。2. 确定性与变异门禁确定性顺序与哈希种子重复测试deterministic order and hash-seed repeats验证结果不受 pytest 收集顺序或 Python 哈希随机化影响有界选择性变异分数门禁bounded selective mutation score gate对选定的变更热点运行有界数量的变异测试并达到分数下限。相关工具在 scripts/prepare_mutation_coverage.py 与 scripts/run_prepared_mutmut.py 中落地并有 tests/test_mutmut_coverage_sitecustomize.py 等测试验证其自身契约。3. Windows 与跨平台契约Windows checkpoint 契约Windows checkpoint contracts核验检查点写入/恢复逻辑在 Windows 文件系统语义下成立。4. 供应链策略lock / workflow / package / secret / vulnerability / license六类检查全部由 ci/supply-chain-policy.json 定义决策详见第六节。5. 唯一确定性交付物发布工作流创建且仅创建一次一个确定性的git archive源码 ZIP一个与 ZIP 摘要绑定的CycloneDX SBOM一份SHA256SUMS清单SLSA 溯源SLSA provenanceSigstore bundles密钥无关签名。文档强调包任务创建源码 ZIP 一次。下游验证与发布必须复用这些精确字节重建等价归档是不可接受的。这意味着 ZIP 是经测试、经认证的唯一实体任何下游都不能用内容相同为理由替换它。OBLITERATUS 发布物形态仅源码一个重要事实OBLITERATUS 的发布不发布 wheel、sdist、可执行文件或编译库。发布物只有经过认证的源码快照。这一选择与 README.md 中发布者不提供预编译产物、由使用者自行构建的定位一致也让供应链核验收敛为一个 ZIP 绑定证据的单一事实源。六、供应链策略机器可读的例外即失败体系精确 Tag 认证中的供应链门禁不是空泛原则而是 ci/supply-chain-policy.json 中可直接执行的决策漏洞策略全严重级别失败decision: fail-all-severities, fail_severities: [unknown, low, medium, high, critical], max_fixed_suppression_days: 7, max_unfixed_suppression_days: 90策略文件明确说明原因OSV 并不保证为每条公告提供归一化严重级别因此未知/低/中/高/严重一律视为阻断——这比仅高严重级别才阻断更严格避免了缺失严重级别数据的公告被静默放过。异常suppression规则为可修复漏洞最多豁免 7 天无修复方案的漏洞最多豁免 90 天。密钥策略所有发现即失败decision: fail-all-findings, report_redaction_percent: 100, max_suppression_days: 30Gitleaks 检查的每一个密钥发现都是阻断性的报告以 100% 脱敏形式保留密钥异常最多持续 30 天且必须记录脱敏后的 Gitleaks 指纹。许可策略精确允许名单许可元数据必须精确匹配allowed_expressions名单中的某一项如Apache-2.0、MIT、MPL-2.0 AND MIT等不支持许可例外。OBLITERATUS 自身excluded_packages: [obliteratus]被排除在依赖许可评估之外因为 AGPL 是其项目许可而非第三方依赖决策。异常纪律异常只能存在于ci/supply-chain-policy.json中命令行忽略与无条件成功转换被明令禁止过期、超长、陈旧、格式错误或未使用的异常都会导致 CI 失败已获得修复方案的漏洞不能使用声明为无修复的异常常规依赖或工具更新不得仅仅为了让 CI 变绿而新增异常。固定工具与锁定依赖ci/digests.txt 记录了 CI 使用的每个 action 与工具的不可变固定值类型名称固定值actionactions/checkoutv7.0.1commit pinactionactions/setup-pythonv7.0.0actionactions/upload-artifactv7.0.1actionactions/download-artifactv8.0.1actionactions/attestv4.2.2SLSA provenance / SBOM attestationtoolrhysd/actionlintv1.7.12sha256 pintoolastral-sh/uvv0.12.4toolgitleaks/gitleaksv8.30.1sha256 pin依赖侧仓库提交的uv.lock是 Python 3.10–3.12 测试矩阵的可复现依赖唯一来源包含精确版本、源 URL、环境标记与产物哈希。CI 仅从 PyTorch 显式包索引安装 CPU 版 PyTorch其余包全部从 PyPI 解析。更新锁定依赖的标准操作文档给出了升级 lockfile 的标准命令注意版本号来自ci/digests.txt中记录的 uv 固定值uvx --from uv0.12.4 uv lock --upgrade uvx --from uv0.12.4 uv lock --check升级后必须完整审阅 lock 差异、源索引、新许可、漏洞证据与 SBOM 差异并在同一个 PR中同步更新pyproject.toml的直接固定与ci/digests.txt的可执行文件固定/校验和。供应链证据的保留与核验供应链任务Supply chain job为每次认证保留 14 天的证据一份脱敏的 Gitleaks JSON 报告、三个 Python 版本在 Linux 上的 OSV 审计 JSON 与扫描状态、全部支持 extras 的 JSON 许可清单、绑定到仓库 ZIP 的 CycloneDX 1.5 源码 SBOM以及策略决策与所测源码 ZIP。消费者可执行的可移植完整性检查sha256sum --check SHA256SUMS但文档特别提醒校验和只证明字节完整性不证明谁构建了产物、以及它由哪份源码和哪些构建指令产生。真实性与来源必须通过 Sigstore 无密钥签名与 SLSA 溯源核验。七、条件化证据发布前的最后一公里验证docs/RELEASE_PROCESS.md明确指出发布前维护者需针对精确 tag 提交手动运行适用的托管软件门禁hosted software gates包括固定的模型/评估门禁pinned model/evaluation一次性网络服务门禁disposable network-service操作员 UI 门禁operator-UI。硬件或凭证绑定门禁CUDA、bitsandbytes、Jetson、MPS、MLX、远程执行仅在其可信前置条件可用时运行。这些门禁的完整语义由 docs/conditional-testing.md 与 ci/conditional-test-policy.json 定义。两个关键语义未被选中的门禁不是正面证据not_selected_no_fresh_evidence是显式状态不代表后端支持。证据过期阈值是 8 天保留期为 30 天。豁免waiver阻断对应支持声明环境豁免最多持续 30 天必须命名一个门禁、一个 canonical 跟踪 issue、原因、起止日期与它阻断的支持声明。当前加速器豁免CUDA/bitsandbytes/MPS/MLX/远程执行由 issue #110 跟踪原因均为已验证硬件存在但未注册 GitHub 自托管 runner——豁免不是该后端可用的证据它只是诚实声明我们尚未在此环境上认证。门禁内容示例以model-download-runtime门禁为例ci/conditional-test-policy.json仅下载hf-internal-testing/tiny-random-gpt271034c5d8bde858ff824298bdedc65515b97d2b9trust_remote_codeFalse缓存键包含模型修订、Python 版本与 runner OS执行一次前向传播随后以 Hub/Transformers 离线模式重开缓存断言未缓存模型在离线时加载失败在两个 tiny 样本上运行评估器超时 25 分钟预期下载低于 100 MB。其覆盖路径coverage_paths包括obliteratus/architecture_profiles.py、obliteratus/abliterate.py、obliteratus/informed_pipeline.py、obliteratus/models/loader.py等——与风险映射中这些模块登记的model-download-runtime门禁一一对应。本地复现条件门禁条件测试文档提供了在本地复现托管门禁的标准命令uv sync --locked --extra dev uv run --extra dev python scripts/run_conditional_gate.py model-download-runtime uv run --extra dev python scripts/run_conditional_gate.py external-evaluation uv run --extra dev python scripts/run_conditional_gate.py network-services uv sync --locked --all-extras uv run --all-extras python scripts/run_conditional_gate.py operator-ui结果语义非常严格scripts/run_conditional_gate.py要求至少执行一个测试并拒绝任何失败、错误或跳过。被选中的任务不能通过可用性跳过或无条件成功转换变绿最终摘要只要有任何选中任务不成功就失败。发布事件触发再验证发布publication动作本身会再次触发条件化工作流发布事件运行必须同样成功完成并作为最终发布记录final release record保留。也就是说条件化证据存在发布前手动运行 发布事件自动重跑两轮确认。八、发布时序全景从 tag 到发布物结合 docs/SUPPLY_CHAIN_POLICY.md 与 docs/RELEASE_PROCESS.md一次发布的完整时序为维护者准备发布候选五步收口更新版本号并创建签名标注 tag推送v*tag 触发 exact-tag 工作流测试矩阵、覆盖率、变异、Windows 契约、供应链六类检查全部通过包任务用git archive创建唯一源码 ZIP输出SHA256SUMS与绑定 ZIP 的 CycloneDX SBOMSigstore 无密钥服务签署两份 in-toto 声明覆盖SHA256SUMS所有 subject 的 SLSA 构建溯源、以及将 SBOM 绑定到 ZIP 摘要的 SBOM 声明供应链任务下载包任务的保留产物核验SHA256SUMS、复验 SBOM 绑定不得创建替代归档同时运行 Gitleaks/OSV/许可检查并保留 14 天证据维护者针对精确 tag 手动运行适用的条件化托管门禁确保证据成功且新鲜8 天窗口内以草稿形式组装发布比对上传资产摘要与已核验的工作流输出全部条件满足后发布发布事件再次触发条件化工作流并作为最终记录保留。文档明确提交、依赖锁、快照指令、产物、校验和清单、SBOM 或发布策略的任何变更都会使既有证据失效——因此发布认证是快照级而非分支级的。九、对研究型项目的启示与验证清单作为研究型工具OBLITERATUS 的发布流程有三个可借鉴的工程取向研究声明必须有可复现证据支撑接受标准中研究/性能声明不得超过所提供可复现证据直接嵌入 PR 评审门禁质量阈值分层PR 快车道50% 变更行覆盖率与发布套件75% 仓库语句 / 94% 成熟 CPU 语句 / 85% 变异分数明确分档既不阻塞贡献者也不稀释发布标准证据链可独立核验源码 ZIP SHA256SUMS SBOM SLSA Sigstore 构成谁、用什么源码、在什么构建指令下、产出什么字节的完整闭环且所有下游都必须复用最初认证的字节。发布认证的最终状态是精确签名v*tag 干净 canonical 提交 全部门禁通过 独立核验的源码快照与证据。任何一个环节缺失或陈旧发布都不得进行——这保证了发布物可以被任何第三方独立复核而不只是CI 说绿了。延伸阅读pull-request acceptance and release process本文主题文档四阶段状态机与认证时序的权威表述Supply-chain policy锁文件、确定性 ZIP、SBOM/SLSA/签名与异常体系的完整细节Conditional test operations条件门禁选择、新鲜度、runner 隔离与豁免语义ci/supply-chain-policy.json漏洞/密钥/许可的机器可读决策ci/conditional-test-policy.json十个条件门禁的定义、前置条件、预期成本与覆盖路径ci/test-quality-policy.json发布级覆盖率、变异分数与测试时长预算ci/test-risk-map.json模块风险分级与条件门禁映射ci/pr-test-policy.jsonPR 快车道测试选择与基础设施测试ci/digests.txtaction 与工具的不可变固定清单CONTRIBUTING.md贡献者侧的签名与协作要求。【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OBLITERATUS 发布流程实战指南：从 PR 审核到精确 Tag 认证的端到端质量门禁
OBLITERATUS 发布流程实战指南从 PR 审核到精确 Tag 认证的端到端质量门禁【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS导读本文围绕 docs/RELEASE_PROCESS.md 展开系统讲解 OBLITERATUS 项目如何将贡献者反馈、维护者验收、主线集成与发布认证四个环节彻底分离并以此构建机器可读策略驱动、精确 SHA 绑定、证据可独立核验的发布管线。读完本文你将掌握该项目的四阶段 PR 状态机、发布候选的完整准备步骤、v*精确 Tag 的发布认证门禁清单、确定性源码快照与 SBOM/SLSA 证据链的生成与核验方法以及条件化证据conditional evidence与豁免waiver在发布中的语义边界。OBLITERATUS 是面向大语言模型拒绝行为研究abliteration的开源工具包其发布流程贯穿研究可信度与软件供应链安全两条主线一条是仓库级覆盖率、变异测试分数、风险映射等质量门禁另一条是锁定依赖、确定性源码 ZIP、CycloneDX SBOM、SLSA 溯源与 Sigstore 签名组成的交付物证据链。两者共同决定了一次发布成立的最低事实标准。一、核心原则绿 PR 不是接受决定OBLITERATUS 发布流程的第一个设计原则在文档开头即被点明Pull-request check 通过是必要条件但它本身不构成接受acceptance或发布release决定。换句话说贡献者侧绿灯只是入场券。真正具有权威性的是两样东西被强制执行的工作流enforced workflows即 CI 中按机器可读策略实际运行的检查机器可读策略文件machine-readable policies即仓库中ci/目录下由 JSON 表达的、可被 CI 直接消费的门禁定义。文档本身只是向维护者解释如何应用这些策略而策略文件才是权威来源。这一设计让人维护者判断与机自动门禁各司其职机器保证事实下限维护者负责超出机器范围的审计判断。二、四阶段 PR 状态机发布流程将一次变更的生命周期严格划分为四个状态每个状态都有明确的准入/退出条件状态含义关键约束Reviewable可评审精确的 PR head 已签名、无冲突、贡献者侧检查全绿相关行为有聚焦的测试覆盖描述中明确列出未运行的测试、风险面与证据边界Accepted已接受维护者对不可变的 head SHA 完成审计审计覆盖正确性、研究诚信、安全、兼容性、文档及适用的策略/风险映射变更Integrated已集成已接受的 head 以仓库配置的 merge-commit 方式合入主线不使用 squash / rebase 合并生成的 canonicalmain提交必须具有 forge 验证签名合入后 CI 必须通过Release-certified已发布认证干净 canonical 提交上的精确签名v*tag 通过全部必需发布门禁产出的源码快照与证据已独立核验两个容易被忽略的细节新提交会使审计失效Accepted状态的审计绑定的是不可变的 head SHA。一旦 head 上出现新提交该审计即失效必须对新 head 重新检查。不接受 squash / rebase 合并Integrated状态严格要求使用仓库配置的 merge-commit 方法目的是让 canonicalmain的历史保持每次合并都可追溯到一个已审计 SHA的结构。此外文档允许维护者在接受前以独立署名、已签名的提交补充测试深度或加固hardening但明确禁止为了促成合并而削弱任何阈值、断言、必需任务或风险映射。源码佐证PR 快车道fast lane的策略表达快车道比发布套件更窄这一原则在 ci/pr-test-policy.json 中有量化表达变更行覆盖率下限为50%changed_line_coverage_floor: 50.0无论变更范围如何始终运行的测试always_tests包括tests/test_module_imports.py、tests/test_cli_boundaries.py、tests/test_runtime_contracts.py、tests/test_abliterate.py、tests/test_strategies.py基础设施路径.github/workflows/**、ci/**、pyproject.toml、uv.lock、scripts/check_*.py等触发对应的基础设施测试集如tests/test_ci_policy.py、tests/test_supply_chain_policy.py、tests/test_quality_policy.pytests/conditional/前缀的测试被明确排除在快车道之外——它们走的是 条件化测试文档 描述的独立门禁。[ci/test-quality-policy.json](https://link.gitcode.com/i/2fbaaf9850879f544fc485a16523de06)则定义了发布级的质量下限详见本文第四节两套阈值的分层正是快车道窄、发布套件宽的工程落地。三、接受标准什么情况下 PR 不能被接受文档用否定式清单定义了接受边界——满足以下任一条件即禁止接受被评审的 head SHA 与当前 head 不一致存在无法验证签名的提交必需检查处于 pending、failing、stale 状态或附着于其他 SHA相关行为没有有意义的测试或契约覆盖仍存在未解决的评审讨论、冲突、无法解释的生成文件、无关变更或未处理的信任边界风险研究/性能声明超出了所提供可复现证据的范围依赖、工作流、策略、文档或兼容性影响没有包含在同一可评审变更中。最后一条值得展开依赖、工作流、策略、文档或兼容性影响必须同变更一并评审。这与 ci/digests.txt 记录的依赖更新纪律一脉相承——工具固定与依赖升级不是可以悄悄附带在功能 PR 里的小事而是供应链政策的一部分。信任边界风险的工程含义[ci/test-risk-map.json](https://link.gitcode.com/i/0b4ab63acd566946b06deb4898f5d43c)是这一原则的机器化形式它将全部源码模块按cpu-contract、mixed-runtime、conditional-runtime三种风险类别分级并给每个模块绑定required_tests与conditional_gates。例如obliteratus/device.py属于mixed-runtime必需测试为tests/test_device_boundaries.py并挂接cuda-runtime、jetson-runtime、mps-runtime三个条件门禁obliteratus/models/loader.py同时挂接model-download-runtime、cuda-runtime、jetson-runtime、bitsandbytes-runtime四个门禁obliteratus/remote.py挂接remote-execution门禁。这意味着无法在标准 CI 中运行的环境绑定逻辑不再是评审盲区而是被显式登记为条件门禁的覆盖对象——这正是文档所说相关行为没有有意义的测试或契约覆盖时不得接受的具体落实。四、发布候选准备五步收口当所有已接受的工作合入后维护者进入发布候选release candidate准备流程共五步核对托管队列清理 pull-request 与 issue 队列确认没有悬而未决的变更清理与同步删除已合并分支确认main干净且已同步核验签名与 CI确认 canonical 合并签名有效、合入后 CI 全部通过运行就绪套件针对精确候选运行详尽的本地或托管就绪套件readiness suite版本与打签更新项目版本号创建新的签名标注标签signed annotated tag。其中针对精确候选运行不是套话——发布门禁全部绑定到v*tag 对应的具体提交而不是main 分支的最新状态。这也是第五步版本号 签名 tag必须在就绪套件通过之后执行的原因。Tag 不可变审计记录文档对失败候选的处理写得非常明确Tags are immutable audit records. A failed candidate is not moved, deleted, or reused.即tag 是不可变的审计记录。失败的候选不会被移动、删除或复用它保持未发布状态留在历史中修正后的候选使用新的补丁版本号和新的签名 tag。从供应链视角看docs/SUPPLY_CHAIN_POLICY.md 的表述失败的 tag 保留为不可变、未发布的审计记录修正候选使用新版本——发布编号是一次性的这保证了任何下载者都能精确对应哪一个提交的哪一次认证。五、精确 Tag 发布认证exact-tag workflow 门禁清单推送v*tag 会触发针对该 tag 提交的详尽发布工作流文档列举了四大类门禁1. 跨版本测试矩阵与覆盖率下限Python3.10 / 3.11 / 3.12三版本测试import / CLI 冒烟检查仓库与分支覆盖率下限repository and branch coverage floors关键文件下限critical-file floors成熟 CPU 作用域策略mature CPU-scope policy触及模块无回归对比touched-module no-regression comparison。这些阈值在 ci/test-quality-policy.json 中量化为指标下限仓库语句覆盖率repository_statement75.0%仓库分支覆盖率repository_branch60.0%变更行覆盖率changed_line50.0%成熟 CPU 作用域语句覆盖率mature_cpu_statement94.0%成熟 CPU 作用域分支覆盖率mature_cpu_branch84.0%变异测试分数mutation_score85.0%警告预算warning_budget0该策略还列出了 13 个关键 CPU 路径critical_cpu_paths包括obliteratus/runtime_contracts.py、obliteratus/models/loader.py、obliteratus/cli.py、obliteratus/telemetry.py等——这些文件承担运行时契约、加载边界、CLI 解析与遥测等对正确性最敏感的逻辑是发布认证的强制覆盖对象。成熟 CPU 作用域通过mature_cpu_scope.exclusions精确定义15 个必须真实模型运行时、外部服务、交互 UI 或远程/硬件执行才能覆盖的模块如obliteratus/abliterate.py、obliteratus/remote.py、obliteratus/local_ui.py被显式排除并逐条登记其conditional_gate——排除了却不登记门禁CI 就会失败。这是边界透明化而非放水。2. 确定性与变异门禁确定性顺序与哈希种子重复测试deterministic order and hash-seed repeats验证结果不受 pytest 收集顺序或 Python 哈希随机化影响有界选择性变异分数门禁bounded selective mutation score gate对选定的变更热点运行有界数量的变异测试并达到分数下限。相关工具在 scripts/prepare_mutation_coverage.py 与 scripts/run_prepared_mutmut.py 中落地并有 tests/test_mutmut_coverage_sitecustomize.py 等测试验证其自身契约。3. Windows 与跨平台契约Windows checkpoint 契约Windows checkpoint contracts核验检查点写入/恢复逻辑在 Windows 文件系统语义下成立。4. 供应链策略lock / workflow / package / secret / vulnerability / license六类检查全部由 ci/supply-chain-policy.json 定义决策详见第六节。5. 唯一确定性交付物发布工作流创建且仅创建一次一个确定性的git archive源码 ZIP一个与 ZIP 摘要绑定的CycloneDX SBOM一份SHA256SUMS清单SLSA 溯源SLSA provenanceSigstore bundles密钥无关签名。文档强调包任务创建源码 ZIP 一次。下游验证与发布必须复用这些精确字节重建等价归档是不可接受的。这意味着 ZIP 是经测试、经认证的唯一实体任何下游都不能用内容相同为理由替换它。OBLITERATUS 发布物形态仅源码一个重要事实OBLITERATUS 的发布不发布 wheel、sdist、可执行文件或编译库。发布物只有经过认证的源码快照。这一选择与 README.md 中发布者不提供预编译产物、由使用者自行构建的定位一致也让供应链核验收敛为一个 ZIP 绑定证据的单一事实源。六、供应链策略机器可读的例外即失败体系精确 Tag 认证中的供应链门禁不是空泛原则而是 ci/supply-chain-policy.json 中可直接执行的决策漏洞策略全严重级别失败decision: fail-all-severities, fail_severities: [unknown, low, medium, high, critical], max_fixed_suppression_days: 7, max_unfixed_suppression_days: 90策略文件明确说明原因OSV 并不保证为每条公告提供归一化严重级别因此未知/低/中/高/严重一律视为阻断——这比仅高严重级别才阻断更严格避免了缺失严重级别数据的公告被静默放过。异常suppression规则为可修复漏洞最多豁免 7 天无修复方案的漏洞最多豁免 90 天。密钥策略所有发现即失败decision: fail-all-findings, report_redaction_percent: 100, max_suppression_days: 30Gitleaks 检查的每一个密钥发现都是阻断性的报告以 100% 脱敏形式保留密钥异常最多持续 30 天且必须记录脱敏后的 Gitleaks 指纹。许可策略精确允许名单许可元数据必须精确匹配allowed_expressions名单中的某一项如Apache-2.0、MIT、MPL-2.0 AND MIT等不支持许可例外。OBLITERATUS 自身excluded_packages: [obliteratus]被排除在依赖许可评估之外因为 AGPL 是其项目许可而非第三方依赖决策。异常纪律异常只能存在于ci/supply-chain-policy.json中命令行忽略与无条件成功转换被明令禁止过期、超长、陈旧、格式错误或未使用的异常都会导致 CI 失败已获得修复方案的漏洞不能使用声明为无修复的异常常规依赖或工具更新不得仅仅为了让 CI 变绿而新增异常。固定工具与锁定依赖ci/digests.txt 记录了 CI 使用的每个 action 与工具的不可变固定值类型名称固定值actionactions/checkoutv7.0.1commit pinactionactions/setup-pythonv7.0.0actionactions/upload-artifactv7.0.1actionactions/download-artifactv8.0.1actionactions/attestv4.2.2SLSA provenance / SBOM attestationtoolrhysd/actionlintv1.7.12sha256 pintoolastral-sh/uvv0.12.4toolgitleaks/gitleaksv8.30.1sha256 pin依赖侧仓库提交的uv.lock是 Python 3.10–3.12 测试矩阵的可复现依赖唯一来源包含精确版本、源 URL、环境标记与产物哈希。CI 仅从 PyTorch 显式包索引安装 CPU 版 PyTorch其余包全部从 PyPI 解析。更新锁定依赖的标准操作文档给出了升级 lockfile 的标准命令注意版本号来自ci/digests.txt中记录的 uv 固定值uvx --from uv0.12.4 uv lock --upgrade uvx --from uv0.12.4 uv lock --check升级后必须完整审阅 lock 差异、源索引、新许可、漏洞证据与 SBOM 差异并在同一个 PR中同步更新pyproject.toml的直接固定与ci/digests.txt的可执行文件固定/校验和。供应链证据的保留与核验供应链任务Supply chain job为每次认证保留 14 天的证据一份脱敏的 Gitleaks JSON 报告、三个 Python 版本在 Linux 上的 OSV 审计 JSON 与扫描状态、全部支持 extras 的 JSON 许可清单、绑定到仓库 ZIP 的 CycloneDX 1.5 源码 SBOM以及策略决策与所测源码 ZIP。消费者可执行的可移植完整性检查sha256sum --check SHA256SUMS但文档特别提醒校验和只证明字节完整性不证明谁构建了产物、以及它由哪份源码和哪些构建指令产生。真实性与来源必须通过 Sigstore 无密钥签名与 SLSA 溯源核验。七、条件化证据发布前的最后一公里验证docs/RELEASE_PROCESS.md明确指出发布前维护者需针对精确 tag 提交手动运行适用的托管软件门禁hosted software gates包括固定的模型/评估门禁pinned model/evaluation一次性网络服务门禁disposable network-service操作员 UI 门禁operator-UI。硬件或凭证绑定门禁CUDA、bitsandbytes、Jetson、MPS、MLX、远程执行仅在其可信前置条件可用时运行。这些门禁的完整语义由 docs/conditional-testing.md 与 ci/conditional-test-policy.json 定义。两个关键语义未被选中的门禁不是正面证据not_selected_no_fresh_evidence是显式状态不代表后端支持。证据过期阈值是 8 天保留期为 30 天。豁免waiver阻断对应支持声明环境豁免最多持续 30 天必须命名一个门禁、一个 canonical 跟踪 issue、原因、起止日期与它阻断的支持声明。当前加速器豁免CUDA/bitsandbytes/MPS/MLX/远程执行由 issue #110 跟踪原因均为已验证硬件存在但未注册 GitHub 自托管 runner——豁免不是该后端可用的证据它只是诚实声明我们尚未在此环境上认证。门禁内容示例以model-download-runtime门禁为例ci/conditional-test-policy.json仅下载hf-internal-testing/tiny-random-gpt271034c5d8bde858ff824298bdedc65515b97d2b9trust_remote_codeFalse缓存键包含模型修订、Python 版本与 runner OS执行一次前向传播随后以 Hub/Transformers 离线模式重开缓存断言未缓存模型在离线时加载失败在两个 tiny 样本上运行评估器超时 25 分钟预期下载低于 100 MB。其覆盖路径coverage_paths包括obliteratus/architecture_profiles.py、obliteratus/abliterate.py、obliteratus/informed_pipeline.py、obliteratus/models/loader.py等——与风险映射中这些模块登记的model-download-runtime门禁一一对应。本地复现条件门禁条件测试文档提供了在本地复现托管门禁的标准命令uv sync --locked --extra dev uv run --extra dev python scripts/run_conditional_gate.py model-download-runtime uv run --extra dev python scripts/run_conditional_gate.py external-evaluation uv run --extra dev python scripts/run_conditional_gate.py network-services uv sync --locked --all-extras uv run --all-extras python scripts/run_conditional_gate.py operator-ui结果语义非常严格scripts/run_conditional_gate.py要求至少执行一个测试并拒绝任何失败、错误或跳过。被选中的任务不能通过可用性跳过或无条件成功转换变绿最终摘要只要有任何选中任务不成功就失败。发布事件触发再验证发布publication动作本身会再次触发条件化工作流发布事件运行必须同样成功完成并作为最终发布记录final release record保留。也就是说条件化证据存在发布前手动运行 发布事件自动重跑两轮确认。八、发布时序全景从 tag 到发布物结合 docs/SUPPLY_CHAIN_POLICY.md 与 docs/RELEASE_PROCESS.md一次发布的完整时序为维护者准备发布候选五步收口更新版本号并创建签名标注 tag推送v*tag 触发 exact-tag 工作流测试矩阵、覆盖率、变异、Windows 契约、供应链六类检查全部通过包任务用git archive创建唯一源码 ZIP输出SHA256SUMS与绑定 ZIP 的 CycloneDX SBOMSigstore 无密钥服务签署两份 in-toto 声明覆盖SHA256SUMS所有 subject 的 SLSA 构建溯源、以及将 SBOM 绑定到 ZIP 摘要的 SBOM 声明供应链任务下载包任务的保留产物核验SHA256SUMS、复验 SBOM 绑定不得创建替代归档同时运行 Gitleaks/OSV/许可检查并保留 14 天证据维护者针对精确 tag 手动运行适用的条件化托管门禁确保证据成功且新鲜8 天窗口内以草稿形式组装发布比对上传资产摘要与已核验的工作流输出全部条件满足后发布发布事件再次触发条件化工作流并作为最终记录保留。文档明确提交、依赖锁、快照指令、产物、校验和清单、SBOM 或发布策略的任何变更都会使既有证据失效——因此发布认证是快照级而非分支级的。九、对研究型项目的启示与验证清单作为研究型工具OBLITERATUS 的发布流程有三个可借鉴的工程取向研究声明必须有可复现证据支撑接受标准中研究/性能声明不得超过所提供可复现证据直接嵌入 PR 评审门禁质量阈值分层PR 快车道50% 变更行覆盖率与发布套件75% 仓库语句 / 94% 成熟 CPU 语句 / 85% 变异分数明确分档既不阻塞贡献者也不稀释发布标准证据链可独立核验源码 ZIP SHA256SUMS SBOM SLSA Sigstore 构成谁、用什么源码、在什么构建指令下、产出什么字节的完整闭环且所有下游都必须复用最初认证的字节。发布认证的最终状态是精确签名v*tag 干净 canonical 提交 全部门禁通过 独立核验的源码快照与证据。任何一个环节缺失或陈旧发布都不得进行——这保证了发布物可以被任何第三方独立复核而不只是CI 说绿了。延伸阅读pull-request acceptance and release process本文主题文档四阶段状态机与认证时序的权威表述Supply-chain policy锁文件、确定性 ZIP、SBOM/SLSA/签名与异常体系的完整细节Conditional test operations条件门禁选择、新鲜度、runner 隔离与豁免语义ci/supply-chain-policy.json漏洞/密钥/许可的机器可读决策ci/conditional-test-policy.json十个条件门禁的定义、前置条件、预期成本与覆盖路径ci/test-quality-policy.json发布级覆盖率、变异分数与测试时长预算ci/test-risk-map.json模块风险分级与条件门禁映射ci/pr-test-policy.jsonPR 快车道测试选择与基础设施测试ci/digests.txtaction 与工具的不可变固定清单CONTRIBUTING.md贡献者侧的签名与协作要求。【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考