后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本文围绕 doc/integration-program/consolidation/build-preparation.md 展开讲述 Elsa 生态Core、Extensions、Studio 三个仓库以保留原始 Git 历史为目标合并时如何先在可丢弃的历史排练仓库中把导入项目接入 Core 的规范Elsa.sln并通过规范的 NUKETest目标验证构建兼容性。读完本文你将掌握rehearse-import.py与prepare_consolidated_build.py的完整工作流、可复现的命令序列、双模式项目引用验证方法以及这套流程对构建通过与真实导入/发布之间边界的严格界定。一、背景一次为历史承载导入做的可丢弃构建实验Elsa 的源代码分布在 Core、Extensions、Studio 等多个仓库中。为了将 Extensions 与 Studio 的历史完整并入 Core同时不丢失任何原始祖先提交需要一种既能在合并前验证构建可行性、又不会污染真实仓库的方法。本次构建准备对应程序 #8194、feature #8214、story #8286、task #8287正是这样的一次性构建实验它在历史排练之后执行但不是历史承载导入本身也不是发布候选。这篇文档的定位可以从三个约束看出不触碰真实仓库所有工作都在新建的可丢弃排练仓库中进行不替代历史证据更早的Consolidated.sln构建与定向测试结果仍是独立的历史证据不能用来证明规范解决方案不提前宣示成功一次成功的 NUKETest运行只证明所选 profile 加四个补充补丁可行并不验证当前 Coremain或历史承载导入。理解这一点是阅读后续所有数字与结论的前提——文档中每个成功都严格绑定到具体的源提交 pin。二、记录输入与三种评审过的源 profile1. 原始排练 profile原始排练使用以下三个精确提交仓库提交Core8e893e02c4ac089d526b0a0d294a8546f021d072Extensions33fa0bfd28c7585240e3d4f665058c067b17e287Studio9afd3e36fd1bc90dfdf8ea00b40d89e4a50c8822upstream-work.json 记录了之后对仓库 tip 与开放 PR head 的只读刷新。关键纪律是那些更新的 tip 不会被静默替换进观察结果。在准备真实导入前需要刷新并核对这份台账保留原始祖先与活跃贡献者分支。该排练保住了9,635 个文件 blob/模式Core 5,864、Extensions 1,665、Studio 2,106以及三段原始历史。五个冲突的 Secrets 项目在既有的搬迁策略下继续以惰性.source证据形式保留其余遗留的 Secrets API/Core/Models/Management/Scripting 项目则因兼容性工作而保留。文档特别强调一次成功构建并不授权同时注册两套端点也不授权切换现有数据库。2. 076 与 95a 两个后续 profile在原始基线之外准备工具还评审并允许了两个更靠后的 Core pincore-076 profileCore076f022cc174d497af26fc8e26414970e61a79b1合并了凭据生命周期、工作流绑定以及 EF/BPMN 的 compare-and-swap 修正core-95a658 follow-up profileCore95a658b96107ad4dbb280a13972479af74bc6a30选定时曾被验证为当时的 Coremain但台账另行记录之后验证的 Coremaintip77f3ca92eb3e514af959404f67ea538b07cba98f。两个检查中 Extensions 与 Studiomain都停留在记录 pin 上。Core 076 是 95a 的祖先且两者在这些受跟踪的构建输入上 blob 完全一致Directory.Build.props、Directory.Build.targets、Directory.Packages.props、NuGet.Config、src/Directory.Build.props、build/Build.cs两个 pin 都没有根级global.json。两者在解决方案成员上有明确差异——95a 的解决方案新增了 PostgreSQL 凭据持久化项目、PostgreSQL 凭据集成测试项目和 Secrets API 集成测试项目同时integration-program-tools.yml与secrets-api-studio-contract.yml两个 CI workflow 有变化而包发布 workflowpackages.yml保持不变。一次仅路径层面的筛选发现185 个源集成补丁路径与 076 之后变动的 277 个 Core 路径没有任何重叠。这些对比由 canonical-source-profile-ledger.json 完整保留。95a 的原始排练保住了全部9,993 个源 blob/模式与三段原始历史准备器评估了167 个项目的导入/新增属性矩阵而规范Elsa.sln总共含343 个项目条目。在此之上又应用了四个面向当前 main 的兼容性/测试布局补丁才运行规范的 NUKE 验证。任意 Core 提交仍然被拒绝只有经过验证的源树、原始父提交、完整搬迁映射和干净工作区才被接受收据会记录实际选中的提交。三、可重复的三步准备流程步骤 1创建历史排练rehearse-import.py准备流程的起点是 rehearse-import.py。以 95a follow-up profile 为例git -C /path/to/new-rehearsal checkout rehearsal git -C /path/to/new-rehearsal restore --sourceHEAD --worktree . python3 scripts/integration-program/prepare_consolidated_build.py \ --rehearsal /path/to/new-rehearsal对应地创建排练仓库本身使用python3 scripts/integration-program/rehearse-import.py \ --core /path/to/elsa-core \ --extensions /path/to/elsa-extensions \ --studio /path/to/elsa-studio \ --output /tmp/elsa-rehearsal从源码看该脚本的核心约束包括完整历史硬性要求任一源仓库若为浅克隆--is-shallow-repository为 true会直接报错提示先fetch --unshallow固定的重定位规则RULESExtensions 的src/modules/、src/workbench/、test/、doc/分别映射到src/extensions/、samples/extensions/workbench/、test/extensions/、doc/extensions/Studio 的src/、tests/、samples/、doc/、docs/、specs/、artwork/、postman/分别映射到src/studio/、test/studio/、samples/studio/、doc/studio/、doc/studio/docs/、specs/studio/、doc/studio/artwork/、doc/studio/postman/冲突保留DUPLICATES五个 Secrets 持久化/Studio 项目会被定向到doc/integration-program/legacy/{product}/{path}.source作为惰性证据其余未纳入显式规则的项目同样落到.source路径输出位置与安全性输出目录必须在所有源仓库之外且不能已存在排练提交以三棵源树为父提交合成并以rehearsal分支形式落地同时执行fsck --full校验所有可达历史收据写入import-receipt.json记录源提交、排练提交、文件计数与完整映射并明确保留buildCompatibilityVerified: false字段。步骤 2准备器prepare_consolidated_build.pyprepare_consolidated_build.py 是本次实验的核心工具它的行为从源码中可以逐条确认输入验证从固定的 Git 树重算搬迁映射验证所有父提交与精确的排练树并拒绝以下任一情况——被跟踪的编辑、remote、意外文件包括被 ignore 的文件、收据漂移、源 pin 不一致。它从不重置或删除用户的工作补丁应用仅在git apply --check通过后应用已评审的补丁并以--whitespaceerror严格校验解决方案生成为每个导入项目用uuid.uuid5(uuid.NAMESPACE_URL, elsa-canonical-build: path)生成稳定 GUID写入Elsa.sln并拒绝路径包含..、引号、换行的不安全项目路径属性矩阵评估对每个项目 ×Debug/Release×default/source/package三种引用模式对应UseProjectReferences未设/true/false评估TargetFramework(s)、PackageId、IsPackable、GeneratePackageOnBuild、UseProjectReferences并递归评估每个内层目标框架任何IsPackable ! false、GeneratePackageOnBuild ! false或PackageId缺失/跨矩阵不稳定都会导致失败收据与报告写出约定的consolidated-build-receipt.json与canonical-packability-report.json。收据保留既有buildCompatibilityVerified: false字段并新增规范解决方案专属字段canonicalBuildAndTestsVerified在规范构建与测试门禁运行前保持false。需要特别强调这些是属性评估检查不是编译、测试、打包或发布执行。SDK 选择以可丢弃排练仓库为根每次 MSBuild 评估都从其项目目录运行准备器不提交、不推送、不发布。对已准备过的 checkout 再次运行会被拒绝——补丁变化时应保留日志并另建可丢弃排练。信任边界同样明确该工具信任本地 Git 安装与已评审的工具/补丁构建额外信任已安装的 SDK、环境、用户 NuGet 配置与缓存。应使用受信任的开发账户本次准备不是沙箱也不是封闭发布证明。步骤 3补丁整合的实质内容补丁将166 个映射导入项目 1 个新增回归测试项目test/extensions/modules/agents/Elsa.Studio.Agents.Tests/Elsa.Studio.Agents.Tests.csproj接入 Core 的规范解决方案并做以下处理将引用重写为本地 Core/Studio/Extensions 项目保留各自上游的中心依赖基线central package management外部 CShells 依赖继续以包形式存在修复被搬迁的资产路径将构建属性/目标限定到各自作用域测试/样例的中心版本包装器导入对应源基线而不是重复它。矩阵只评估有效包身份与排除属性不创建、不检查.nupkg文件仓库原有的发布 workflow 在此可丢弃排练中保持惰性不会被该变更激活。Fody 行为也限定在其原产品内不会静默继承 Core 不同的守卫。测试项目选择与 NUKE 选择器的一致性导入的test/extensions与test/studio下的.csproj清单还会与 build/Build.cs 中 NUKE 的TestProjects选择器核对——该选择器取解决方案中名字以Tests结尾的项目。固定清单共有 17 个 test-tree 项目16 个匹配选择器而Elsa.TestServer.Web是唯一一个因作为宿主而被有意排除在测试执行之外的项目。规范的 NUKE 运行最终选择了 95 个解决方案测试项目含两棵清单之外的项目全部新增解决方案项目都保留在默认解决方案构建中。精确的选择路径与项目/框架结果记录在 canonical-95a-nuke-test-evidence.json。四、Slack 项目的双模式引用验证可复现实战搬迁后的Elsa.Slack保留上游的双模式 Elsa 依赖UseProjectReferencesfalse时Elsa.Slack.csproj保留PackageReference IncludeElsaUseProjectReferencestrue时改用映射到 Core 的../../../modules/Elsa/Elsa.csproj项目引用。包引用由导入的 Extensions 中心包基线定版本记录 pin 上ElsaVersion为3.8.0-preview.5557。这对包验证很重要评估或构建项目引用模式并不能证明包模式的依赖成立。准备完成后两种模式都应检查dotnet msbuild src/extensions/communication/Elsa.Slack/Elsa.Slack.csproj \ -getProperty:PackageId,AssemblyName,RootNamespace,ElsaVersion,ManagePackageVersionsCentrally \ -getItem:PackageReference,ProjectReference -p:UseProjectReferencesfalse dotnet msbuild src/extensions/communication/Elsa.Slack/Elsa.Slack.csproj \ -getProperty:PackageId,AssemblyName,RootNamespace,ElsaVersion,ManagePackageVersionsCentrally \ -getItem:PackageReference,ProjectReference -p:UseProjectReferencestrue2026-09-24 的检查基于原始 profile 通过包模式评估出PackageId/AssemblyName/RootNamespace均为Elsa.Slack只有一个 Elsa 包引用、无项目引用源模式评估出相同身份与映射的 Core 项目引用、无 Elsa 包引用。这仅为 MSBuild 评估没有 restore/build/pack因此不能替代对生成.nuspec的检查参见 NuGet 关于PackageReference条件的 MSBuild 条件语义说明。后续的 mapped-slack-package-proof.md 只从这个源映射布局中把Elsa.Slack打包进本地 feed、检查其.nuspec、在干净纯包项目里消费它并按字节校验内嵌 C# 源与 Extensions pin 的一致性。该包证明与公开 3.8.4 制品对比使用 Core33181ae3...与 Extensions154ba15f...是两回事。五、两个显式写入补丁的兼容性修复补丁中写明了两个已诊断的兼容性变更Agents 不再依赖 Studio 间接提供的已归档 Blazored.FluentValidation。按钮与表单提交流程都改为等待既有的异步 name validator并引入组件自有消息存储、陈旧响应修订守卫与销毁守卫。新增六个测试覆盖待定唯一性、重复消息、含改回change-back的字段变更、直接名称变更、竞争响应与销毁场景。源码佐证见 prepare_consolidated_build.py 的remove_unused_blazored_references——它会移除Elsa.Studio.Agents.csproj与Elsa.Studio.WorkflowContexts.csproj中孤立的 Blazored 引用组。BlazorApp1样例清理继承的TargetFrameworks仅保留其声明的net8.0。此前继承的组合会把多框架资产版本还原进单框架构建引发 CustomElements 静态资产冲突。六、验证结果与剩余门禁1. 076 profile 的属性矩阵保留证据在已准备好的 076 profileSDK 10.0.300上运行过纯属性矩阵评估全部 167 个导入/新增项目、2,586 个框架/配置/引用模式用例所有有效PackageId非空且稳定所有用例IsPackablefalse且GeneratePackageOnBuildfalse排练 Git 状态不变。压缩证据 canonical-packability-076-evidence.json.gz 的 SHA-256 为640afa1a61b472fb2f054312168a11c6ba85595a312441976785dd04ac7537a7。这是保留的 076 证据不是 95a 规范证明。2. 95a profile 的属性矩阵与规范 NUKE 运行95a 规范Elsa.sln含 343 个总项目条目准备器矩阵覆盖 167 个导入/新增项目。SDK 10.0.300 评估了 2,586 个 Debug/Release、默认/源/包引用用例全部包身份稳定非空、全部IsPackablefalse与GeneratePackageOnBuildfalse。规范可打包性报告 SHA-256 为5b720229d7f58da91a4c62aaf19670acea6212638c013dfcc676713fba6b5d18准备收据 SHA-256 为5fd5df724698e010932a741633936a12d39e506743195482b33e68d9154d0238。该评估发生在四个补充补丁应用之前因此不独立确立它们的有效包属性四个补丁的精确哈希列在 canonical-source-profile-ledger.json 中。规范的 NUKE 命令env -u NUKE_ENTERPRISE_TOKEN ./build.sh --host Terminal --target Test于 2026-09-24 退出码 0Restore 用时 19 秒Compile 4:530 错误、1,570 警告Test 9:10NUKE 摘要为6,056 通过、148 跳过、0 失败。完整日志保存于/tmp/elsa-8194/95a-canonical-compile-test.logSHA-25639b8e102204e1f2a02029acc3589d3b8d982ec94fdffd61f5a547e7e393ffe2b。选定项目清单含 95 个唯一项目命令路径与 94 个保留的 TRX 文件控制台摘要显示跨声明目标框架6,222 通过net8/net9/net10 的 Designer 各通过 83 个测试但 NUKE 固定的每项目 TRX 文件名只保留了 net9 的 TRX。两份保留的测试结果文件包含 0 个已执行用例Azure Service Bus 显式跳过的 TODO 与 Slack 未实现跳过的测试Elsa.Workflows.PerformanceTests被选定并构建但没有测试 SDK未产生测试运行/TRX。这些异常均在机器可读证据中逐条记录。当前运行 6,222 个全框架通过数比历史 076Consolidated.sln的 6,169 多 53 个21 个原先失败的 Studio 路径解析测试现在通过32 个用例新增在 Connections、Secrets、Workflow Core、Credentials PostgreSQL 集成与 Secrets API 集成中。两个 profile 都报告 148 个跳过用例——由于源/解决方案 profile 不同数字不能理解为覆盖范围相同。1,570 个编译警告包括依赖安全公告NU1902/NU1903、Pomelo EF 版本约束 NU1608、NETSDK1206、XML cref、可空/编译器、裁剪、xUnit/MudBlazor 分析器以及无 remote 的 SourceLink 警告。引用的公告仍未解决本次证据运行未包含任何依赖变更。没有任何 Pack、Push 或 Publish target 运行。3. 历史Consolidated.sln证据与阻塞项文档保留了 2026-09-23 原始可丢弃实验的表格证据WorkflowContexts 模块 32 警告通过、修复前全解决方案 25 错误失败、修复后 Agents 122 警告通过、6 个 Agents 回归测试通过、net8 样例 70 警告通过、第二次排练重放成功、准备安全性回归 77 通过。完整构建还暴露了 Dapper 与 MongoDB 缺少IWorkflowDefinitionStore.TryUpdateLatestAsync实现这两个阻塞项分别在 #8293Dapper与 #8294MongoDB跟踪需要真实的租户作用域数据库 compare-and-sap 行为含原子 old/new 版本切换抛异常桩或进程内锁都不满足契约#8292 则单独修复了一个可能在 store 加载 compare-and-swap 快照前覆盖中间元数据的文档编辑调用方。076 的 current-core-build.md 记录了 340 项目Consolidated.sln构建成功0 错误、1,867 警告SDK 10.0.300 / macOS arm6417m51s与 214 个定向测试通过那是历史结果不是规范Elsa.sln验证。文档明确要求不要从属性矩阵或这个Testtarget 推断根级Pack成功或发布成功本次实验也不确立完整解决方案测试、公开包兼容性、可发布的 SourceLink、迁移宿主认证、最终布局下的浏览器/调试器行为或 Secrets 数据库/端点兼容性——这些仍是程序级整合门禁。4. 后续证据链provider-build.md 记录了 Dapper/Mongo 补丁与规范 Secrets 样例修正后的完整排练构建成功修正后增量构建 0 错误、1,561 警告另 12 个 Mongo 测试通过以及此前被 restore 阻塞的 Logging/LDAP/MQTT/Quartz 五项目 107 个测试通过。studio-test-layout.md 保留了后续完整测试运行6,169 通过、21 个路径解析失败、148 跳过以及修复三个受影响项目后的 103 个测试通过且不把最初完整运行重新标记为成功。七、结论构建准备与真实导入的边界不要推送合成的排练提交。真实导入必须在兼容性与发布门禁通过后以普通 merge 保留源祖先的方式执行包发布、生产/切换与仓库归档保留明确的批准边界。判断某个结果是否成立始终要看它绑定的源 pin8e 基线、076 评审 profile 与 95a 允许列表 follow-up pin 是三个不同的证据集95a不是当前 Coremain。从源码结构看prepare_consolidated_build.py 的SUPPORTED_CORE_PROFILE_COMMITS显式允许列表正是这种只认评审 pin、拒绝任意提交纪律的落地。属性矩阵、编译、定向测试、打包证明是四件不同的事矩阵证明不会误打包编译证明能编译NUKETest证明选定测试通过mapped-slack-package-proof证明单个包可消费。它们叠加起来也不等于可以发布——SourceLink、安全公告、宿主 CI、完整依赖闭包与最终布局调试仍是独立的待办门禁。对于任何想要在 Elsa 多仓库整合中复用这套方法的人最值得带走的三条纪律是用可丢弃排练隔离一切实验副作用把每次结果绑定到精确 pin 与补丁哈希让构建通过停留在它自己的证据边界内不与发布授权混为一谈。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐Claude SEO 实战FLOW Optimize 阶段的 Follow-Up Qualifying Prompt——证据筛选、优先级排序与发布前验证清单Claude SEO 实战FLOW Optimize 阶段的 Follow Up Qualifying Prompt——证据筛选、优先级排序与发布前验证清单Audiblez一条命令把 epub 转成有声书的开源工具完整零基础指南Audiblez一条命令把 epub 转成有声书的开源工具完整零基础指南 Audiblez 是一款开源的有声书生成工具读入一个 epub 电子书文件一AI 应用语音音频本地部署深入JD-Eclipse架构揭秘Java字节码反编译的实现原理深入JD Eclipse架构揭秘Java字节码反编译的实现原理 JD Eclipse是一款强大的Java反编译Eclipse插件能够帮助开发者将Java字节上一篇Labelme界面字体大小调整适应高分辨率屏幕的设置下一篇DVC与MLflow模型注册表集成完整的模型生命周期管理终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Elsa 多仓库历史整合的规范构建准备：rehearse-import 与 prepare_consolidated_build 深度实践
后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本文围绕 doc/integration-program/consolidation/build-preparation.md 展开讲述 Elsa 生态Core、Extensions、Studio 三个仓库以保留原始 Git 历史为目标合并时如何先在可丢弃的历史排练仓库中把导入项目接入 Core 的规范Elsa.sln并通过规范的 NUKETest目标验证构建兼容性。读完本文你将掌握rehearse-import.py与prepare_consolidated_build.py的完整工作流、可复现的命令序列、双模式项目引用验证方法以及这套流程对构建通过与真实导入/发布之间边界的严格界定。一、背景一次为历史承载导入做的可丢弃构建实验Elsa 的源代码分布在 Core、Extensions、Studio 等多个仓库中。为了将 Extensions 与 Studio 的历史完整并入 Core同时不丢失任何原始祖先提交需要一种既能在合并前验证构建可行性、又不会污染真实仓库的方法。本次构建准备对应程序 #8194、feature #8214、story #8286、task #8287正是这样的一次性构建实验它在历史排练之后执行但不是历史承载导入本身也不是发布候选。这篇文档的定位可以从三个约束看出不触碰真实仓库所有工作都在新建的可丢弃排练仓库中进行不替代历史证据更早的Consolidated.sln构建与定向测试结果仍是独立的历史证据不能用来证明规范解决方案不提前宣示成功一次成功的 NUKETest运行只证明所选 profile 加四个补充补丁可行并不验证当前 Coremain或历史承载导入。理解这一点是阅读后续所有数字与结论的前提——文档中每个成功都严格绑定到具体的源提交 pin。二、记录输入与三种评审过的源 profile1. 原始排练 profile原始排练使用以下三个精确提交仓库提交Core8e893e02c4ac089d526b0a0d294a8546f021d072Extensions33fa0bfd28c7585240e3d4f665058c067b17e287Studio9afd3e36fd1bc90dfdf8ea00b40d89e4a50c8822upstream-work.json 记录了之后对仓库 tip 与开放 PR head 的只读刷新。关键纪律是那些更新的 tip 不会被静默替换进观察结果。在准备真实导入前需要刷新并核对这份台账保留原始祖先与活跃贡献者分支。该排练保住了9,635 个文件 blob/模式Core 5,864、Extensions 1,665、Studio 2,106以及三段原始历史。五个冲突的 Secrets 项目在既有的搬迁策略下继续以惰性.source证据形式保留其余遗留的 Secrets API/Core/Models/Management/Scripting 项目则因兼容性工作而保留。文档特别强调一次成功构建并不授权同时注册两套端点也不授权切换现有数据库。2. 076 与 95a 两个后续 profile在原始基线之外准备工具还评审并允许了两个更靠后的 Core pincore-076 profileCore076f022cc174d497af26fc8e26414970e61a79b1合并了凭据生命周期、工作流绑定以及 EF/BPMN 的 compare-and-swap 修正core-95a658 follow-up profileCore95a658b96107ad4dbb280a13972479af74bc6a30选定时曾被验证为当时的 Coremain但台账另行记录之后验证的 Coremaintip77f3ca92eb3e514af959404f67ea538b07cba98f。两个检查中 Extensions 与 Studiomain都停留在记录 pin 上。Core 076 是 95a 的祖先且两者在这些受跟踪的构建输入上 blob 完全一致Directory.Build.props、Directory.Build.targets、Directory.Packages.props、NuGet.Config、src/Directory.Build.props、build/Build.cs两个 pin 都没有根级global.json。两者在解决方案成员上有明确差异——95a 的解决方案新增了 PostgreSQL 凭据持久化项目、PostgreSQL 凭据集成测试项目和 Secrets API 集成测试项目同时integration-program-tools.yml与secrets-api-studio-contract.yml两个 CI workflow 有变化而包发布 workflowpackages.yml保持不变。一次仅路径层面的筛选发现185 个源集成补丁路径与 076 之后变动的 277 个 Core 路径没有任何重叠。这些对比由 canonical-source-profile-ledger.json 完整保留。95a 的原始排练保住了全部9,993 个源 blob/模式与三段原始历史准备器评估了167 个项目的导入/新增属性矩阵而规范Elsa.sln总共含343 个项目条目。在此之上又应用了四个面向当前 main 的兼容性/测试布局补丁才运行规范的 NUKE 验证。任意 Core 提交仍然被拒绝只有经过验证的源树、原始父提交、完整搬迁映射和干净工作区才被接受收据会记录实际选中的提交。三、可重复的三步准备流程步骤 1创建历史排练rehearse-import.py准备流程的起点是 rehearse-import.py。以 95a follow-up profile 为例git -C /path/to/new-rehearsal checkout rehearsal git -C /path/to/new-rehearsal restore --sourceHEAD --worktree . python3 scripts/integration-program/prepare_consolidated_build.py \ --rehearsal /path/to/new-rehearsal对应地创建排练仓库本身使用python3 scripts/integration-program/rehearse-import.py \ --core /path/to/elsa-core \ --extensions /path/to/elsa-extensions \ --studio /path/to/elsa-studio \ --output /tmp/elsa-rehearsal从源码看该脚本的核心约束包括完整历史硬性要求任一源仓库若为浅克隆--is-shallow-repository为 true会直接报错提示先fetch --unshallow固定的重定位规则RULESExtensions 的src/modules/、src/workbench/、test/、doc/分别映射到src/extensions/、samples/extensions/workbench/、test/extensions/、doc/extensions/Studio 的src/、tests/、samples/、doc/、docs/、specs/、artwork/、postman/分别映射到src/studio/、test/studio/、samples/studio/、doc/studio/、doc/studio/docs/、specs/studio/、doc/studio/artwork/、doc/studio/postman/冲突保留DUPLICATES五个 Secrets 持久化/Studio 项目会被定向到doc/integration-program/legacy/{product}/{path}.source作为惰性证据其余未纳入显式规则的项目同样落到.source路径输出位置与安全性输出目录必须在所有源仓库之外且不能已存在排练提交以三棵源树为父提交合成并以rehearsal分支形式落地同时执行fsck --full校验所有可达历史收据写入import-receipt.json记录源提交、排练提交、文件计数与完整映射并明确保留buildCompatibilityVerified: false字段。步骤 2准备器prepare_consolidated_build.pyprepare_consolidated_build.py 是本次实验的核心工具它的行为从源码中可以逐条确认输入验证从固定的 Git 树重算搬迁映射验证所有父提交与精确的排练树并拒绝以下任一情况——被跟踪的编辑、remote、意外文件包括被 ignore 的文件、收据漂移、源 pin 不一致。它从不重置或删除用户的工作补丁应用仅在git apply --check通过后应用已评审的补丁并以--whitespaceerror严格校验解决方案生成为每个导入项目用uuid.uuid5(uuid.NAMESPACE_URL, elsa-canonical-build: path)生成稳定 GUID写入Elsa.sln并拒绝路径包含..、引号、换行的不安全项目路径属性矩阵评估对每个项目 ×Debug/Release×default/source/package三种引用模式对应UseProjectReferences未设/true/false评估TargetFramework(s)、PackageId、IsPackable、GeneratePackageOnBuild、UseProjectReferences并递归评估每个内层目标框架任何IsPackable ! false、GeneratePackageOnBuild ! false或PackageId缺失/跨矩阵不稳定都会导致失败收据与报告写出约定的consolidated-build-receipt.json与canonical-packability-report.json。收据保留既有buildCompatibilityVerified: false字段并新增规范解决方案专属字段canonicalBuildAndTestsVerified在规范构建与测试门禁运行前保持false。需要特别强调这些是属性评估检查不是编译、测试、打包或发布执行。SDK 选择以可丢弃排练仓库为根每次 MSBuild 评估都从其项目目录运行准备器不提交、不推送、不发布。对已准备过的 checkout 再次运行会被拒绝——补丁变化时应保留日志并另建可丢弃排练。信任边界同样明确该工具信任本地 Git 安装与已评审的工具/补丁构建额外信任已安装的 SDK、环境、用户 NuGet 配置与缓存。应使用受信任的开发账户本次准备不是沙箱也不是封闭发布证明。步骤 3补丁整合的实质内容补丁将166 个映射导入项目 1 个新增回归测试项目test/extensions/modules/agents/Elsa.Studio.Agents.Tests/Elsa.Studio.Agents.Tests.csproj接入 Core 的规范解决方案并做以下处理将引用重写为本地 Core/Studio/Extensions 项目保留各自上游的中心依赖基线central package management外部 CShells 依赖继续以包形式存在修复被搬迁的资产路径将构建属性/目标限定到各自作用域测试/样例的中心版本包装器导入对应源基线而不是重复它。矩阵只评估有效包身份与排除属性不创建、不检查.nupkg文件仓库原有的发布 workflow 在此可丢弃排练中保持惰性不会被该变更激活。Fody 行为也限定在其原产品内不会静默继承 Core 不同的守卫。测试项目选择与 NUKE 选择器的一致性导入的test/extensions与test/studio下的.csproj清单还会与 build/Build.cs 中 NUKE 的TestProjects选择器核对——该选择器取解决方案中名字以Tests结尾的项目。固定清单共有 17 个 test-tree 项目16 个匹配选择器而Elsa.TestServer.Web是唯一一个因作为宿主而被有意排除在测试执行之外的项目。规范的 NUKE 运行最终选择了 95 个解决方案测试项目含两棵清单之外的项目全部新增解决方案项目都保留在默认解决方案构建中。精确的选择路径与项目/框架结果记录在 canonical-95a-nuke-test-evidence.json。四、Slack 项目的双模式引用验证可复现实战搬迁后的Elsa.Slack保留上游的双模式 Elsa 依赖UseProjectReferencesfalse时Elsa.Slack.csproj保留PackageReference IncludeElsaUseProjectReferencestrue时改用映射到 Core 的../../../modules/Elsa/Elsa.csproj项目引用。包引用由导入的 Extensions 中心包基线定版本记录 pin 上ElsaVersion为3.8.0-preview.5557。这对包验证很重要评估或构建项目引用模式并不能证明包模式的依赖成立。准备完成后两种模式都应检查dotnet msbuild src/extensions/communication/Elsa.Slack/Elsa.Slack.csproj \ -getProperty:PackageId,AssemblyName,RootNamespace,ElsaVersion,ManagePackageVersionsCentrally \ -getItem:PackageReference,ProjectReference -p:UseProjectReferencesfalse dotnet msbuild src/extensions/communication/Elsa.Slack/Elsa.Slack.csproj \ -getProperty:PackageId,AssemblyName,RootNamespace,ElsaVersion,ManagePackageVersionsCentrally \ -getItem:PackageReference,ProjectReference -p:UseProjectReferencestrue2026-09-24 的检查基于原始 profile 通过包模式评估出PackageId/AssemblyName/RootNamespace均为Elsa.Slack只有一个 Elsa 包引用、无项目引用源模式评估出相同身份与映射的 Core 项目引用、无 Elsa 包引用。这仅为 MSBuild 评估没有 restore/build/pack因此不能替代对生成.nuspec的检查参见 NuGet 关于PackageReference条件的 MSBuild 条件语义说明。后续的 mapped-slack-package-proof.md 只从这个源映射布局中把Elsa.Slack打包进本地 feed、检查其.nuspec、在干净纯包项目里消费它并按字节校验内嵌 C# 源与 Extensions pin 的一致性。该包证明与公开 3.8.4 制品对比使用 Core33181ae3...与 Extensions154ba15f...是两回事。五、两个显式写入补丁的兼容性修复补丁中写明了两个已诊断的兼容性变更Agents 不再依赖 Studio 间接提供的已归档 Blazored.FluentValidation。按钮与表单提交流程都改为等待既有的异步 name validator并引入组件自有消息存储、陈旧响应修订守卫与销毁守卫。新增六个测试覆盖待定唯一性、重复消息、含改回change-back的字段变更、直接名称变更、竞争响应与销毁场景。源码佐证见 prepare_consolidated_build.py 的remove_unused_blazored_references——它会移除Elsa.Studio.Agents.csproj与Elsa.Studio.WorkflowContexts.csproj中孤立的 Blazored 引用组。BlazorApp1样例清理继承的TargetFrameworks仅保留其声明的net8.0。此前继承的组合会把多框架资产版本还原进单框架构建引发 CustomElements 静态资产冲突。六、验证结果与剩余门禁1. 076 profile 的属性矩阵保留证据在已准备好的 076 profileSDK 10.0.300上运行过纯属性矩阵评估全部 167 个导入/新增项目、2,586 个框架/配置/引用模式用例所有有效PackageId非空且稳定所有用例IsPackablefalse且GeneratePackageOnBuildfalse排练 Git 状态不变。压缩证据 canonical-packability-076-evidence.json.gz 的 SHA-256 为640afa1a61b472fb2f054312168a11c6ba85595a312441976785dd04ac7537a7。这是保留的 076 证据不是 95a 规范证明。2. 95a profile 的属性矩阵与规范 NUKE 运行95a 规范Elsa.sln含 343 个总项目条目准备器矩阵覆盖 167 个导入/新增项目。SDK 10.0.300 评估了 2,586 个 Debug/Release、默认/源/包引用用例全部包身份稳定非空、全部IsPackablefalse与GeneratePackageOnBuildfalse。规范可打包性报告 SHA-256 为5b720229d7f58da91a4c62aaf19670acea6212638c013dfcc676713fba6b5d18准备收据 SHA-256 为5fd5df724698e010932a741633936a12d39e506743195482b33e68d9154d0238。该评估发生在四个补充补丁应用之前因此不独立确立它们的有效包属性四个补丁的精确哈希列在 canonical-source-profile-ledger.json 中。规范的 NUKE 命令env -u NUKE_ENTERPRISE_TOKEN ./build.sh --host Terminal --target Test于 2026-09-24 退出码 0Restore 用时 19 秒Compile 4:530 错误、1,570 警告Test 9:10NUKE 摘要为6,056 通过、148 跳过、0 失败。完整日志保存于/tmp/elsa-8194/95a-canonical-compile-test.logSHA-25639b8e102204e1f2a02029acc3589d3b8d982ec94fdffd61f5a547e7e393ffe2b。选定项目清单含 95 个唯一项目命令路径与 94 个保留的 TRX 文件控制台摘要显示跨声明目标框架6,222 通过net8/net9/net10 的 Designer 各通过 83 个测试但 NUKE 固定的每项目 TRX 文件名只保留了 net9 的 TRX。两份保留的测试结果文件包含 0 个已执行用例Azure Service Bus 显式跳过的 TODO 与 Slack 未实现跳过的测试Elsa.Workflows.PerformanceTests被选定并构建但没有测试 SDK未产生测试运行/TRX。这些异常均在机器可读证据中逐条记录。当前运行 6,222 个全框架通过数比历史 076Consolidated.sln的 6,169 多 53 个21 个原先失败的 Studio 路径解析测试现在通过32 个用例新增在 Connections、Secrets、Workflow Core、Credentials PostgreSQL 集成与 Secrets API 集成中。两个 profile 都报告 148 个跳过用例——由于源/解决方案 profile 不同数字不能理解为覆盖范围相同。1,570 个编译警告包括依赖安全公告NU1902/NU1903、Pomelo EF 版本约束 NU1608、NETSDK1206、XML cref、可空/编译器、裁剪、xUnit/MudBlazor 分析器以及无 remote 的 SourceLink 警告。引用的公告仍未解决本次证据运行未包含任何依赖变更。没有任何 Pack、Push 或 Publish target 运行。3. 历史Consolidated.sln证据与阻塞项文档保留了 2026-09-23 原始可丢弃实验的表格证据WorkflowContexts 模块 32 警告通过、修复前全解决方案 25 错误失败、修复后 Agents 122 警告通过、6 个 Agents 回归测试通过、net8 样例 70 警告通过、第二次排练重放成功、准备安全性回归 77 通过。完整构建还暴露了 Dapper 与 MongoDB 缺少IWorkflowDefinitionStore.TryUpdateLatestAsync实现这两个阻塞项分别在 #8293Dapper与 #8294MongoDB跟踪需要真实的租户作用域数据库 compare-and-sap 行为含原子 old/new 版本切换抛异常桩或进程内锁都不满足契约#8292 则单独修复了一个可能在 store 加载 compare-and-swap 快照前覆盖中间元数据的文档编辑调用方。076 的 current-core-build.md 记录了 340 项目Consolidated.sln构建成功0 错误、1,867 警告SDK 10.0.300 / macOS arm6417m51s与 214 个定向测试通过那是历史结果不是规范Elsa.sln验证。文档明确要求不要从属性矩阵或这个Testtarget 推断根级Pack成功或发布成功本次实验也不确立完整解决方案测试、公开包兼容性、可发布的 SourceLink、迁移宿主认证、最终布局下的浏览器/调试器行为或 Secrets 数据库/端点兼容性——这些仍是程序级整合门禁。4. 后续证据链provider-build.md 记录了 Dapper/Mongo 补丁与规范 Secrets 样例修正后的完整排练构建成功修正后增量构建 0 错误、1,561 警告另 12 个 Mongo 测试通过以及此前被 restore 阻塞的 Logging/LDAP/MQTT/Quartz 五项目 107 个测试通过。studio-test-layout.md 保留了后续完整测试运行6,169 通过、21 个路径解析失败、148 跳过以及修复三个受影响项目后的 103 个测试通过且不把最初完整运行重新标记为成功。七、结论构建准备与真实导入的边界不要推送合成的排练提交。真实导入必须在兼容性与发布门禁通过后以普通 merge 保留源祖先的方式执行包发布、生产/切换与仓库归档保留明确的批准边界。判断某个结果是否成立始终要看它绑定的源 pin8e 基线、076 评审 profile 与 95a 允许列表 follow-up pin 是三个不同的证据集95a不是当前 Coremain。从源码结构看prepare_consolidated_build.py 的SUPPORTED_CORE_PROFILE_COMMITS显式允许列表正是这种只认评审 pin、拒绝任意提交纪律的落地。属性矩阵、编译、定向测试、打包证明是四件不同的事矩阵证明不会误打包编译证明能编译NUKETest证明选定测试通过mapped-slack-package-proof证明单个包可消费。它们叠加起来也不等于可以发布——SourceLink、安全公告、宿主 CI、完整依赖闭包与最终布局调试仍是独立的待办门禁。对于任何想要在 Elsa 多仓库整合中复用这套方法的人最值得带走的三条纪律是用可丢弃排练隔离一切实验副作用把每次结果绑定到精确 pin 与补丁哈希让构建通过停留在它自己的证据边界内不与发布授权混为一谈。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐Claude SEO 实战FLOW Optimize 阶段的 Follow-Up Qualifying Prompt——证据筛选、优先级排序与发布前验证清单Claude SEO 实战FLOW Optimize 阶段的 Follow Up Qualifying Prompt——证据筛选、优先级排序与发布前验证清单Audiblez一条命令把 epub 转成有声书的开源工具完整零基础指南Audiblez一条命令把 epub 转成有声书的开源工具完整零基础指南 Audiblez 是一款开源的有声书生成工具读入一个 epub 电子书文件一AI 应用语音音频本地部署深入JD-Eclipse架构揭秘Java字节码反编译的实现原理深入JD Eclipse架构揭秘Java字节码反编译的实现原理 JD Eclipse是一款强大的Java反编译Eclipse插件能够帮助开发者将Java字节上一篇Labelme界面字体大小调整适应高分辨率屏幕的设置下一篇DVC与MLflow模型注册表集成完整的模型生命周期管理终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
