NoxxGames/LiberPrimus-GPU

# ation, but that might not be a translation. Looking at the example: 'Running Naabu' -> '运行 Naabu'. So, 'Running' is translated, 'Naabu' is kept. Here, 'liberprimus-gpu' has no translatable parts except possibly 'gpu', but 'gpu' is a technical term, so keep it. 'liberprimus' might be a name. So, I think I should keep the entire thing as 'liberprimus-gpu'. But to output a translation, I might need to present it in a way that makes sense in Chinese. Perhaps I can treat it as a proper noun and not translate it, but the instruction is to translate the headings. I think for names and technical terms, I keep them in English and only translate the surrounding words if any. In this case, 'liberprimus-gpu' is the entire heading, so I might keep it as is. But let's see the user's instruction: "Translate each of the following headings to Simplified Chinese." So, I need to provide a Chinese version. For proper nouns, I might use the English form or transliterate. But the instruction explicitly says to keep them in English form. So, for 'liberprimus-gpu', I should output 'liberprimus-gpu' as is, but that's not Chinese. However, in the context of translation, when proper nouns are kept, they are still part of the Chinese text. For example, in '运行 Naabu', 'Naabu' is in English, but the heading is in Chinese. So, for 'liberprimus-gpu', since it's all a proper noun, I might output 'liberprimus-gpu' without translation. But to be consistent, I should check if there are any translatable parts. 'liberprimus' might be Latin for 'first book', but in this context, it's likely a project name, so keep in English. 'gpu' is technical. So, I think the translation should be 'liberprimus-gpu'. But let's move to others. [](https://github.com/NoxxGames/LiberPrimus-GPU/actions/workflows/ci.yml) ## 使命 `liberprimus-gpu` 是一个用于保守性《Liber Primus》密码分析实验的可复现研究工作台。该项目在从事任何探索性搜索或 GPU 加速工作之前，维护语料库来源、已解决的基线、变换元数据、运行记录和 CI 门禁。 ## 当前边界与延迟工作 除非标记为安全规则，否则这些不是项目的永久性排除项。它们描述了 Stage 3P 后当前的实现边界，以及在更大规模实验开始前必须保持有界、可审查和可复现的工作。CUDA 和大规模运动被延迟，但未被永久排除。 ### 永久性安全规则 - 任何生成的输出本身都不是一个解决方案。 - 不声称已解决任何《Liber Primus》页面；尚未解决的内容，若无固定的语料库、清单、变换链、可复现输出、测试和审查，不得获得解决声明。 - 不得覆盖或提交原始数据。 - 不得提交生成的输出和 SQLite 数据库。 ### 当前边界 - 规范语料库：不活跃。 - 页面边界：可审查。 - 大规模未解决页面搜索运动：未开始。 - 评分运动：未开始；Stage 3A/3B 的最小化分类评分仅用于排序和检查有界的 841 个候选 CPU 运行，Stage 3C 校准仅使用小型本地对照，Stage 3D 仅将该评分器应用于四密钥显式维吉尼亚预览，Stage 3F 仅将其应用于有界的 48 个候选 LP 证据密钥维吉尼亚包，Stage 3G 仅将其应用于有界的 256 个候选 p56 局部素数减一偏移扫描，Stage 3H 仅将其应用于有界的 64 个候选重置/推进消融实验（包含 100 个负对照），Stage 3I 仅将其应用于有界的 56 个候选历史主题维吉尼亚包，Stage 3J 仅将其应用于有界的 192 个候选梅森数/完全数流探测。 - 视觉/图像衍生观察：仅限注册表和确定性特征摘要，以及确定性审查变换；Stage 3K 记录来源锁定和可审查的观察，Stage 3M 记录确定性的本地图像特征，Stage 3P 生成被忽略的审查变换/联系表。不执行图像衍生的文本实验。 - Cookie/哈希原像工作：Stage 3L 仅测试两个显式 SHA-256 包，记录确切的字节串，不做模糊或部分哈希声明。 - Discord 来源发现：Stage 3N 仅扫描管理员提供的本地 HTML 导出，并仅提交聚合/编辑后的记录。Stage 3O 推动了一个有界、公开安全的编辑后来源发现记录子集。不提交原始日志、消息正文、用户名和私人附件 URL。 - CUDA 实验运动：未开始。 - 正常有界本地 CPU 实验：当通过 `experiments/policies/operator-policy-v0.yaml` 时自动允许。 - 大规模未解决页面运动：未开始。 - 审批包：可选/高风险审计工具，不是策略通过的有界 CPU 项目的默认路径。 - 现有的 CUDA 代码仅为脚手架和冒烟测试基础设施。 ### 延迟的未来工作 - Stage 3Q 审查视觉变换候选者并提升选定的观察、编辑后的 Discord AI 审查包/主题分片，或者如果视觉审查被延迟，则构建一个 OutGuess 回归测试工具。 - 未来用于六十进制或类似楔形文字的数字、二进制点图案、对称性/不对称性和页面图像的视觉数值观察，在成为实验种子前必须保持可审查。 - 搜索运动。 - 在 CPU 引用和一致性测试存在之后的 CUDA 内核。 - 在稳定 CPU/GPU 基线存在之后的基准测试运动。 ### 自 Stage 0A 以来已实施的工作 - 档案和语料库候选基础设施。 - 十个已知的已解决基线测试用例。 - CPU 变换注册表。 - 已解决基线清单运行器。 - JSONL/SQLite 结果存储基础。 - 无原始数据的 GitHub Actions CI。 - CI 门控的一致性检查。 - CPU 探索性实验干运行规划器。 - 用于合成和仅已解决测试用例运行的有界 CPU 执行工具。 - 探索性实验提案和人工审批工作流。 - 审批门控的执行路径（针对已批准的合成/已解决对照）。 - 首个真实的有界探索性实验审批就绪包。 - 常设的有界本地 CPU 策略和队列脚手架。 - 最小化 CPU 凯撒加仿射执行器和针对首个 `841` 个候选有界队列项的分类评分。 - 候选线索检查、精炼分类评分、重新排序和反向有界比较。 - 使用正对照、空对照、负对照、微小明文检查和保守的 Stage 3D 队列建议进行评分校准。 - 针对四个已声明的已知主题密钥的小型显式密钥维吉尼亚预览，包含校准评分和被忽略的生成输出。 - 深度研究方法待办事项摄入、确定性的 Stage 3E 队列计数和干运行执行器支持分类。 - 重置/推进感知的 Stage 3F LP 证据密钥维吉尼亚包执行器和 48 个候选运行。 - 有界的 Stage 3G p56 局部素数减一偏移扫描执行器和 256 个候选运行，以及一个已排队的未来梅森数/完全数探测。 - 共享的 Stage 3H 重置/推进状态机、64 个候选消融运行和 100 个特定于族的负对照。 - 有界的 Stage 3I 历史主题维吉尼亚包运行，包含 14 个已声明密钥和 56 个候选。 - 有界的 Stage 3J 梅森数/完全数流探测，针对有限的已声明指数序列和 192 个候选。 - Stage 3K 历史档案/来源锁定、本地图像元数据、视觉数值观察和 Cookie/哈希文物注册表。 - Stage 3L 有界 SHA-256 Cookie-哈希原像包，针对两个存档的 2013 年 Cookie 文物。 - Stage 3M 确定性本地图像分析 CLI 和视觉特征摘要。 - Stage 3N 管理员批准的 Discord HTML 存档摄入和来源发现索引。 - Stage 3O 隐私保护的 Discord 来源提升、扩展教程和 GitHub Wiki 镜像源生成。 - Stage 3P 确定性图像变换套件、联系表和本地视觉审查索引。 ## 架构摘要 CPU 端负责语料库管理、清单、假设生成、分支搜索、结果来源和人工审查。GPU 端将仅在 CPU 引用实现、一致性测试和基准测试存在之后，才加速大规模常规批量变换-评分工作。 ## 当前状态 当前状态： - Stage 2A：CPU 变换注册表和清单寻址的已解决基线运行器完成。 - Stage 2B：JSONL/SQLite 实验结果存储基础完成。 - Stage 2C：无原始数据的 GitHub Actions CI 完成并加固了锁哈希。 - Stage 2D：CI 门控的模式/文档一致性和清单/结果存储加固完成。 - Stage 2E：CPU 探索性实验清单脚手架和干运行规划器完成。 - Stage 2F：用于合成和仅已解决测试用例运行的有界 CPU 执行工具完成。 - Stage 2G：探索性实验提案和人工审批工作流完成。 - Stage 2H：审批门控的执行路径（针对已批准的合成/已解决对照）完成。 - Stage 2I：首个真实的有界 CPU 探索性实验审批包完成。 - Stage 2J：常设的有界 CPU 自动运行策略和队列脚手架完成。 - Stage 3A：最小化 CPU 凯撒加仿射执行器和分类评分完成。 - Stage 3B：Stage 3A 线索检查、评分精炼、重新排序和反向比较完成。 - Stage 3C：评分校准、空对照、正对照和微小明文检查完成。 - Stage 3D：小型维吉尼亚已知主题密钥列表预览完成。 - Stage 3E：深度研究方法待办事项摄入和有界队列干运行完成。 - Stage 3F：LP 证据密钥维吉尼亚包执行完成。 - Stage 3G：p56 局部素数减一偏移扫描完成。 - Stage 3H：重置/推进消融和特定于族的负对照完成。 - Stage 3I：历史主题维吉尼亚密钥包运行完成。 - Stage 3J：梅森数/完全数小型流探测完成。 - Stage 3K：档案和视觉观察注册表完成。 - Stage 3L：有界 Cookie-哈希原像包完成。 - Stage 3M：确定性本地图像分析完成。 - Stage 3N：管理员批准的 Discord HTML 存档摄入完成。 - Stage 3O：Discord 来源提升和 Wiki 教程镜像完成。 - Stage 3P：确定性图像变换套件和视觉审查索引完成。 - 已知的已解决基线：`10` 个通过注册表/清单路径。 - 测试用例分解：直接翻译 `4` 个，Atbash 族 `3` 个，显式密钥维吉尼亚 `2` 个，p56 素数减一/Phi-素数 `1` 个。 - 规范语料库：不活跃。 - 页面边界：可审查。 - 大规模搜索/评分/CUDA 运动：未开始。 - 最新的有界哈希审查：Stage 3L 针对两个存档的 Cookie/哈希目标测试了 `1809` 个去重的 SHA-256 候选字节串，进行了 `3618` 次精确比较，发现 `0` 个精确匹配；未提出解决声明。 - 最新的图像分析阶段：Stage 3M 分析了 `58` 个被忽略的本地页面图像，生成了 `406` 条组件记录、`58` 条对称性记录、`464` 条位平面记录和 `71` 个仅用于审查的特征候选（在被忽略的输出中）。未进行 OCR、AI/ML 解释、图像衍生搜索或提出解决声明。 - 最新的来源发现阶段：Stage 3O 从 Stage 3N 提取中将 `500` 个公开来源链接、`200` 个方法声明候选和 `200` 个数值观察候选提升为编辑后的审查记录。它拒绝了私人/不安全的链接，扩展了公开教程，并生成了 Wiki 来源页面。原始 Discord 日志、消息正文、用户名、私人 URL 和生成的审查索引保持未提交状态；未提出解决声明。 - 最新的视觉审查阶段：Stage 3P 处理了 `58` 个被忽略的本地页面图像，输出了 `2077` 张衍生审查图像、`59` 张联系表、`58` 个审查页面和 `6` 个仅用于审查的视觉变换候选（在被忽略的输出中）。未进行 OCR、AI/ML 解释、图像衍生搜索或提出解决声明。 - 下一步：Stage 3Q 审查视觉变换候选并提升选定的观察，或构建编辑后的 Discord AI 审查包/主题分片。 ## 如何使用此仓库 1. 按照 [Windows](tutorials/02-windows-setup.md) 或 [Linux](tutorials/03-linux-setup.md) 教程设置 Python 3.12 和本地虚拟环境。 2. 在信任更改之前，运行本地验证堆栈： ``` .\.venv\Scripts\python.exe -m ruff check python/libreprimus tests/python .\.venv\Scripts\python.exe -m pytest -q tests/python .\.venv\Scripts\python.exe -m libreprimus.cli consistency check-all --allow-warnings ``` 3. 保持本地原始材料在本地。原始 Discord 日志、页面图像、文字稿转储、工作簿和 Pastebin 文件默认被忽略。 4. 生成的输出仅用于本地审查。候选转储、图像分析记录、Discord 提取 JSONL、SQLite 数据库和本地审查索引不得提交。 5. 从 [教程索引](tutorials/README.md) 开始，了解仓库概览、已解决基线、有界队列、图像分析、Discord 存档摄入以及来源/观察注册表工作流。 6. GitHub Wiki 镜像教程页面供公开浏览，但仓库教程文件是权威来源。 安全的有界 CPU 实验使用 `experiments/policies/operator-policy-v0.yaml`；它们仅限于 CPU、有预算限制，且无法声称解决。CUDA 工作需要等待 CPU 引用、一致性测试和明确的未来范围。 ## CI 状态 GitHub Actions 在 [NoxxGames/LiberPrimus-GPU Actions](https://github.com/NoxxGames/LiberPrimus-GPU/actions) 运行。CI 是无原始数据、无 CUDA、无机密的，默认不上传生成的语料库或结果产物。真实的来源冒烟检查仅限本地进行，因为 GitHub 托管的运行器上不存在被忽略的原始来源。 ## 教程 从 `tutorials/README.md` 开始。教程涵盖 Windows 和 Linux 设置、本地数据处理、当前 CLI 工具、文字稿对齐、硬件预期和 Codex 辅助开发。 ## - GitHub Wiki: As above, 'GitHub' is kept in English, 'Wiki' can be translated to '维基'. So, 'GitHub 维基'. Wiki 源页面位于 `docs/wiki-source/` 下，并从 `tutorials/` 生成。仓库教程和文档是权威来源；GitHub Wiki 是公共镜像，不得包含原始数据、生成的转储或解决声明。发布前请使用 `scripts/github/validate-wiki-source.ps1` 和 `scripts/github/sync-tutorials-to-wiki.ps1 --DryRun`。 ## 问题和待办事项 问题模板位于 `.github/ISSUE_TEMPLATE/` 下。用于未来工作的种子问题位于 `docs/github/issues/` 下，可以通过 `scripts/github/create-issues.ps1` 幂等地创建。 ## 公开就绪状态 项目可公开阅读文档和脚手架审查。它尚未准备好用于未解决页面的密码分析运动、规范语料库发布或 GPU 加速声明。 ## Windows 快速入门 ``` .\scripts\verify-toolchain.ps1 .\scripts\configure-windows.ps1 cmake --build build\msvc-debug ctest --test-dir build\msvc-debug --output-on-failure ``` 对于 Python： ``` py -3.12 -m venv .venv .\.venv\Scripts\python.exe -m pip install -U pip setuptools wheel .\.venv\Scripts\python.exe -m pip install -e ".[dev]" .\.venv\Scripts\python.exe -m pytest -q .\.venv\Scripts\libreprimus.exe smoke ``` ## 工具链要求 - Windows 11 或兼容的 Windows 10 开发主机。 - Git for Windows。 - CMake 3.26 或更新版本。 - Ninja。 - Python >=3.12,<3.14，推荐 Python 3.12。 - Visual Studio 2022 生成工具（带桌面 C++ 工作负载）。 - 可选的 CUDA Toolkit（用于 CUDA 冒烟构建）。 ## 配置并构建仅 CPU 版本 ``` cmake -S . -B build\msvc-debug -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLPGPU_ENABLE_CUDA=OFF -DLPGPU_BUILD_TESTS=ON cmake --build build\msvc-debug ctest --test-dir build\msvc-debug --output-on-failure ``` 如果在当前 shell 中看不到 `cl.exe`，请运行 `scripts\configure-windows.ps1`，它会定位 `VsDevCmd.bat`。 ## 配置并构建带 CUDA 的版本 CUDA 构建目前仍是可选的，仅为脚手架/冒烟测试。 ``` cmake -S . -B build\cuda-debug -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLPGPU_ENABLE_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89 -DLPGPU_BUILD_TESTS=ON cmake --build build\cuda-debug ctest --test-dir build\cuda-debug --output-on-failure ``` ## Python 环境设置 Python 包提供了冒烟/工具链命令以及旧版摄入、文字稿对齐、配置文件验证、语料库候选生成和已解决测试用例复现。 直接测试用例冒烟： ``` .\.venv\Scripts\python.exe -m libreprimus.cli solved-fixture stage1a-smoke --fixture-dir data/fixtures/solved-pages/direct-translation-v0 --candidate-dir data/normalized/corpus-candidates/rtkd-master-v0-candidate --out-dir data/normalized/solved-baselines/direct-translation-v0 --allow-pending --allow-warnings ``` 所有已知的已解决基线注册表冒烟： ``` .\.venv\Scripts\python.exe -m libreprimus.cli solved-baseline stage2a-smoke --manifest experiments/manifests/solved-baselines/stage2a-all-known-solved-baselines.yaml --out-dir experiments/results/solved-baselines/stage2a --allow-warnings ``` Stage 2B 结果存储冒烟： ``` .\.venv\Scripts\python.exe -m libreprimus.cli result-store stage2b-smoke --solved-baseline-manifest experiments/manifests/solved-baselines/stage2a-all-known-solved-baselines.yaml --result-store-manifest experiments/manifests/result-store/stage2b-solved-baseline-import.yaml --solved-baseline-out-dir experiments/results/solved-baselines/stage2a --result-store-out-dir experiments/results/result-store/stage2b --replace --allow-warnings ``` 本地 Stage 2C CI 复现： ``` .\scripts\ci\run-python-ci.ps1 .\scripts\ci\run-schema-manifest-checks.ps1 ``` ## 仓库结构 - `src/`：C++20 原生脚手架。 - `cuda/`：可选的 CUDA 冒烟脚手架。 - `python/`：Python 编排包。 - `tests/`：C++ 和 Python 冒烟测试。 - `data/`：不可变的原始数据占位符和未来的语料库区域。 - `experiments/`：清单驱动的实验策略和冒烟清单。 - `docs/`：方法论、CUDA、语料库、评分和 Codex 笔记。 - `scripts/`：Windows 验证、引导、配置、清理和 GitHub 辅助脚本。 - `tutorials/`：面向公众的用户教程。 - `.github/`：问题模板和拉取请求模板。 ## 数据策略 `data/raw/` 是不可变的。不要覆盖原始证据、就地规范化或提交真实的原始语料库文件。语料库工作必须使用显式的 SHA-256 锁和文字稿版本元数据。 ## 实验策略 实验由清单驱动。在固定语料库数据、完整变换链、评分元数据、空对照、可复现测试和人工审查到位之前，候选输出绝不应被视为解决。 ## 测试策略 当前测试涵盖 C++ 骨架、Python 包、清单、模式、结果存储、锁哈希、公共文档状态和一致性门禁。未来的 CUDA 内核必须在优化之前拥有 CPU 引用实现、CPU/GPU 一致性测试和基准测试。 ## 下一个里程碑 Stage 2J 用 `experiments/policies/operator-policy-v0.yaml` 中的常设策略和 `experiments/queues/stage2j-bounded-cpu-queue.yaml` 中的队列取代了每个实验的审批作为默认路径。正常的本地 CPU 项目在满足硬性限制时可以自动运行：候选上限 `100000`，运行时间估计 `600` 秒，生成输出预算 `250` MB，仅限 CPU，无 CUDA/云/付费服务，不提交生成的输出，不激活规范语料库，不定稿页面边界，不提出解决声明。 首个凯撒加仿射可审查切片队列项的候选上限为 `841`，符合策略条件。Stage 3A 为该项添加了最小化 CPU 执行器和确定性的分类评分。完整的候选输出仍被忽略，位于 `experiments/results/bounded-auto-runs/stage3a/` 下；提交的研究日志仅总结计数和最高评分元数据。 Stage 3B 检查了 Stage 3A 的顶级候选，精炼了评分器，对 841 个候选进行了重新排序，并运行了反向比较。精炼和反向的顶级线索仍然是 `noisy`。 Stage 3C 使用正的已解决测试用例对照、确定性空对照、负对照和微小明文检查校准了评分。Stage 3D 针对正好四个已声明的密钥运行了保守的小型维吉尼亚已知主题密钥列表预览。顶级密钥是 `LIBER`，校准为 `noisy`。 Stage 3E 摄入深度研究方法待办事项，提交了 `experiments/queues/stage3e-method-backlog.yaml` 和 `experiments/queues/stage3e-bounded-cpu-queue.yaml`，并以确定性计数进行了有界方法的干运行：LP 证据维吉尼亚 `48`，p56 局部素数减一偏移 `256`，历史维吉尼亚 `56`，特定于族的负对照 `100`，重置/推进消融 `64`，素数模/间隙 `256`，梅森数/完全数探测 `192`。 Stage 3F 实现了重置/推进感知的证据密钥维吉尼亚包执行器，并仅运行 `stage3e_vig_lp_evidence_pack_v1`。它执行了 `48` 个候选，记录了密钥/重置/推进元数据，让生成的输出被忽略，且未提出解决声明。 Stage 3G 实现了 p56 局部素数减一偏移扫描执行器，并仅运行 `stage3e_prime_minus_one_offsets_v1`。它执行了 `256` 个候选，记录了偏移/方向/重置元数据，让生成的输出被忽略，将一个未来的 `192` 个候选梅森数/完全数探测添加到队列但不执行，并未提出解决声明。 Stage 3H 实现了共享的重置/推进状态机，并仅运行 `stage3h_reset_advance_ablation_v1`。它跨维吉尼亚和素数流适配器执行了 `64` 个有界候选，记录了重置/推进和元数据支持状态，写入了 `100` 个被忽略的特定于族的负对照，并未提出解决声明。 Stage 3I 复用了有界的维吉尼亚密钥包执行器，并仅运行 `stage3e_vig_history_key_pack_v1`。它针对 14 个已声明的历史主题密钥，在重置模式 `none` 和 `line` 以及推进模式 `runes_only` 和 `token_break_preserving` 下执行了 `56` 个候选。顶级密钥 `SELFRELIANCE` 仍被校准为 `noisy`；生成的输出保持被忽略状态，且未提出解决声明。 Stage 3J 实现了有界的梅森数/完全数流探测，并仅运行 `stage3j_mersenne_prime_stream_tiny_v1`。它从有限的已声明指数序列中执行了 `192` 个候选，报告了 `96` 个重复流签名，让生成的输出被忽略，并未提出解决声明。 ## Stage 1B Atbash 族测试用例 该工作台现在包括已知的已解决反向 Gematria 和旋转反向 Gematria 复现测试用例。这些通过以下方式运行： ``` .\.venv\Scripts\python.exe -m libreprimus.cli solved-fixture stage1b-smoke ` --direct-fixture-dir data/fixtures/solved-pages/direct-translation-v0 ` --atbash-fixture-dir data/fixtures/solved-pages/atbash-family-v0 ` --candidate-dir data/normalized/corpus-candidates/rtkd-master-v0-candidate ` --direct-out-dir data/normalized/solved-baselines/direct-translation-v0 ` --atbash-out-dir data/normalized/solved-baselines/atbash-family-v0 ` --allow-pending ` --allow-warnings ``` 这些测试用例是回归基线，不是新的解决声明。生成的输出保持被忽略状态，且 `canonical_corpus_active=false`。 ## Stage 1C 维吉尼亚基线 Stage 1C 为 `DIVINITY` 和 `FIRFUMFERENFE` 添加了显式密钥维吉尼亚已知解决测试用例复现，并为选定的 `scream314/cicada3301` 和 `lipeeeee/gematria` 文件添加了参考来源锁定。这些仅为来源和测试用例：未解决新页面，未实现密钥搜索，且仍要求 `canonical_corpus_active=false`。 ## Stage 1D 素数流基线 Stage 1D 使用仅 CPU 的 `prime_minus_one_stream` 变换为 p56 `An End` 添加了已知解决复现，并将 `phi_prime_stream` 记录为素数输入的等效别名。p56 十六进制块作为有效载荷检查保留，未合并到明文中。未实现素数流搜索、评分、CUDA 或语料库激活。 ## Stage 2B 结果存储 Stage 2B 为已解决基线回归导入添加了生成的 JSONL 和 SQLite 结果存储。运行记录保留了清单 SHA-256、注册表 SHA-256、git 提交、配置文件/来源来源，并为规范语料库激活、页面边约定稿、搜索、评分、CUDA 和规范信任设置了明确的 false 标志。`experiments/results/result-store/` 下的生成结果存储输出保持被忽略状态，不是发布产物。 ## - Stage 2C CI: 'Stage' translated to '阶段', '2C' kept as is, 'CI' kept in English. So, '阶段 2C CI'. Stage 2C 添加了 `.github/workflows/ci.yml` 加上 `scripts/ci/` 下的本地脚本。CI 是无原始数据、无 CUDA、无机密的，默认不上传生成的语料库或结果产物。Python 作业运行 Ruff、pytest、包冒烟、变换注册表验证、已解决基线清单验证和结果存储清单验证。

标签：Bash脚本, CI门控, CUDA加速, DOS头擦除, GPU工作台, GPU计算, Liber Primus分析, Vectored Exception Handling, 保守实验, 加密分析, 变换元数据, 可复现研究, 实验平台, 实验管理, 密码分析, 密码学, 密码破解, 并行计算, 开源框架, 手动系统调用, 持续集成, 探索搜索, 数据来源, 数据管理, 未来实验, 测试门控, 研究工作台, 研究工具, 谜题解析, 运行记录, 逆向工具, 高性能计算