DAG工作流执行平台

studioMCP

项目愿景

studioMCP 是Haskell首个用于基于DAG的工作室工作流的MCP平台，具有类型化DAG执行、实时MCP表面、Keycloak支持的身份验证、面向浏览器的BFF和Kubernetes前向本地边缘部署路径。

为什么这可以取代DAW/照片/视频工具链的大部分

大多数工作室工作流程都是围绕少量不纯边界的确定性变换的长链。 studioMCP 将这些链视为类型化的DAG，而不是不透明的编辑器会话。这为可重复性、记忆化、更好的总结和更安全的自动化创造了空间。

为什么Haskell是合适的

Haskell是以下内容的所有权层：

• DAG类型和验证
• 面向铁路的结果处理
• 超时语义
• 概要结构
• 记忆密钥推导
• 存储和消息传递合同
• 面向MCP的协议和执行平面

重点不是新奇。关键是要使编排语义难以被意外削弱。

纯DAG执行模型

每个可执行节点都是以下节点之一：

• PureNode：从解释器的角度来看，类型化和确定性
• BoundaryNode：将不纯的工具或服务封装在类型化的合约后面
• SummaryNode：导出最终的不可变运行摘要

服务器只接受经过验证的DAG定义。调用者不会绕过Haskell模型。

面向铁路的结果处理

节点执行返回 Result success failure成功的价值观可以被铭记。故障值是明确的、结构化的、用户可表示的。该系统从不依赖隐藏的异常控制流作为其公共执行模型。

超时语义

每个节点都有一个超时策略。超时被建模为真实的故障结果，而不是基础设施脚注。最终 Summary 必须明确显示超时与语义工具故障。

记忆语义学

成功的纯结果由从规范化输入和执行语义中导出的面向内容的键来解决。不可变输出转到MinIO。更改语义必须生成一个新密钥，而不是覆盖旧密钥。

Pulsar vs MinIO

• Pulsar是飞行中执行状态的真实来源。
• MinIO是用于存储记忆输出、清单、摘要和持久工件的不可变存储。

它们是有意分离的系统，因为它们解决了不同的问题。

存储库体系结构

早期结构：

app/               executable entrypoints
src/               Haskell library modules
test/              unit and integration tests
docker/            Dockerfile and container assets
docker-compose.yaml  one-off outer development container launcher
chart/             Helm deployment source of truth
kind/              local kind cluster configuration
skaffold.yaml      Kubernetes-native development loop config
documents/         governed architecture, development, domain, and tool docs
examples/          sample DAGs and fixtures
.data/             local persistent cluster data ignored by git and Docker builds

文档套件

存储库使用 documents/，不 docs/，用于受管文档套件。开始 文档/README.md 对于指数和 文档/文档_标准.md SSoT规则、Mermaid约束和元数据要求。

当前文档类别：

• architecture/
• development/
• domain/
• engineering/ 用于Kubernetes本机开发策略等工程标准
• operations/
• reference/
• tools/

受管套件是当前状态声明性文档。历史决策轨迹存在于git历史中，而不是ADR文件夹中。

服务器模式

server 模式拥有DAG提交、验证、执行编排、运行状态进展和摘要检索。这是权威的执行路径。

推理模式

inference 模式是用于DAG起草、修复建议、文档问答和操作员协助的本地参考LLM路径。这只是咨询。它不能绕过类型验证或直接改变持久结果。

群集管理CLI

Haskell中支持的操作命令 studiomcp CLI，不在签入的shell帮助程序中。预期的控制平面工作流程是 docker compose run --rm studiomcp studiomcp <subcommand...>。参见 documents/reference/cli_reference.md, 文档/架构/cli_architecture.md，以及 文件/工程/码头_政策.md.

Docker战略

该仓库在以下位置使用一个单级Dockerfile docker/Dockerfile所得到的图像包括Haskell工具链、集群管理工具、应用程序和应用程序， tini，以及 studiomcp 二元的。Compose仅将其用于一次性外部容器命令，而Helm拥有服务器、BFF和工作负载的显式集群内启动。

Kubernetes原生开发

仓库是Kubernetes forward。头盔下 图表/ 定义服务拓扑， skaffold.yaml 仍然是映像构建和部署工具链的一部分，以及 kind/kind_yaml 定义本地集群目标。作曲在 docker-compose.yaml 发射一次性外层 studiomcp 仅用于单个命令的容器；所有应用程序服务（MCP服务器、BFF、Keycloak、Redis、MinIO、Pulsar、PostgreSQL HA）都通过Helm在类集群内运行。控制平面通过nginx入口暴露在 http://localhost:8081 随着 /mcp, /api, /kc，以及 /minio；对象存储数据平面URL保持根目录 http://localhost:9000。规范政策是 文档/工程/k8s_native_dev_policy.md, 文件/工程/码头_政策.md，以及 文件/工程/k8s_storage.md.

FOSS生态系统调查

该项目依赖于现有的工具，而不是重建它们：

• FFmpeg和SoX用于音频/视频转换
• GStreamer用于面向管道的媒体处理
• ImageMagick和OpenCV用于图像处理
• Blender用于渲染/合成边界
• Pulsar用于飞行中执行状态
• MinIO用于不可变对象持久化
• 本地LLM主机，如Ollama或 llama.cpp 用于推理模式

未来音乐工作流程扩展

当前的存储库已经针对媒体工具证明了边界适配器模式，但 长期计划是扩大 studioMCP 进入更广泛的音乐和记谱工作流程平台。这 本节中的项目是计划中的未来工作流，而不是关于当前运行时表面的声明。

两条平台规则塑造了这一扩张：

• Linux+CUDA是一个一流的生产堆栈，通过容器化工人部署 NVIDIA容器运行时。
• Apple Silicon+Metal是一流的本地和工作站堆栈，原生部署在macOS上 无需虚拟化或容器化。

预期的未来工作流系列包括：

演讲、成绩单和本地化工作流程

• Speech transcript and subtitle extraction：摄取音频或视频，使用进行标准化 ffmpeg, 用Whisper家族模型转录并发出转录本， srt，以及 vtt 人工产品。
• Podcast cleanup and transcript preparation：在有用的地方分开茎，去噪并掌握 sox/ffmpeg，生成成绩单，并将掌握的音频和文本工件打包在一起。
• Video localization and caption republishing：提取语音，转录，对齐字幕， 并重新发布带有字幕或本地化的视频衍生品。
• Meeting and rehearsal logs：摄取排练室录音，生成可搜索的成绩单， 并附上运行摘要和工件参考以供以后检索。

音频DSP和Stem工作流程

• Stem separation：使用以下方法将混合音乐分为声乐、鼓、贝司和伴奏声部 ANN支持的源分离模型。
• Stem cleanup and remix packaging：将茎分支成清理节点，然后重新混合和 重新发布备选声乐/器乐包。
• Karaoke preparation：从单个项目构建器乐、声乐和抒情定时交付成果 源混合。
• Tempo-safe practice tracks：用以下方式拉伸或压缩节奏 rubberband 在保持间距的同时， 然后掌握结果以供排练使用。
• Pitch-shifted practice tracks：将伴奏转换为玩家友好的按键，无需 重新录制源材料。
• Reference mastering and delivery normalization：使响度正常化，调整静音，检查媒体 用于下游工作流的元数据和包稳定输出格式。

自动音乐转录和MIR工作流程

• Baseline audio-to-MIDI transcription：将独奏或简单的合成音音频转换为MIDI 快速符号捕捉。
• Multi-instrument transcription：首先分离茎，然后转录多个乐器和 将符号输出合并为面向分数的通用表示。
• Vocal melody transcription：从歌曲中提取音符级或轮廓级的声乐旋律，或 排练需要。
• Drum-event transcription：制作适合图表的鼓事件时间表，进行节拍感知编辑， 或练习循环。
• Chord, key, beat, and tempo analysis：导出可以馈送的谐波和时间描述符 排列、搜索和编目工作流程。
• Section and similarity analysis：计算用于搜索的结构指纹和描述符， 重复检测、翻唱歌曲分析和库索引。
• Lead-sheet extraction from audio：将旋律转录与和弦分析相结合，产生 录音的第一遍引导页。

符号排列和转换工作流程

• Transcription cleanup：量化音符开始和持续时间，分割声音，规范度量，以及 在安排或雕刻之前修复象征性文物。
• Automatic transposition：将乐谱转换为不同的键或转换乐器，同时 保留符号语义。
• Part extraction：从满分中推导出每个乐器的部分，并将其作为独立部分发布 人工产品。
• Piano reduction and condensed score generation：将较大的合奏素材缩减为可玩内容 钢琴或浓缩指挥乐谱。
• Ensemble arrangement generation：将符号材料映射到SATB、弦乐、管、节奏部分， 或其他目标组合。
• Difficulty reduction：为学生或业余爱好者简化节奏、范围、密度和纹理 表演者。
• Harmonic annotation：为理论生成罗马数字、和弦符号和结构注释， 排练和教学工作流程。
• Round-trip audition：使用以下命令将符号输出渲染回音频 fluidsynth 所以安排 可以在不离开工作流系统的情况下查看更改。

符号、雕刻和出版工作流程

• Deterministic engraving：转换 MusicXML 或其他符号来源雕刻 pdf, svg, 和 png 通过确定性符号后端对伪影进行评分。
• Browser score preview：渲染 MusicXML 直接在网页表面进行轻量级审查， 以用于制造、批准和工件检查。
• Score package publishing：捆绑完整乐谱、提取部分、排练音频、点击曲目和 将元数据合并到一个可发布的工件集中。
• Format normalization：转换 MIDI, MusicXML、分数编辑器格式和预览 资产，因此下游消费者反对规范表示。
• Playback proofing：将雕刻或转换后的乐谱还原为音频，并将其与 符号源，用于捕获符号和导出回归。

OMR、归档和库工作流

• Scan and PDF to editable score：通过OMR摄取乐谱图像或PDF并将其转换 转换为可编辑的符号表示法。
• OMR review loop：将机器识别与浏览器或桌面分数审查配对，以便操作员可以 在发布之前修复低置信度输出。
• Archive normalization of mixed catalogs：摄取扫描PDF的传统组合，符号 文件、MIDI和音频，然后将它们标准化为规范的符号和预览工件。
• Music library indexing：提取描述符、符号摘要和可搜索元数据 大型音乐收藏。
• Version and cover comparison：比较录音或乐谱的关键、节奏、编排和 结构在不同版本之间漂移。

未来ANN推理策略

未来的音乐堆栈包括几个ANN支持的工具和模型。我们想要Linux+CUDA和苹果 硅+金属要成为一流公民，但不应该被迫进行同样的部署 形状。

• Linux+CUDA应该更喜欢具有NVIDIA容器运行时、稳定固定的容器化worker Python环境和面向GPU的推理引擎，如TensorRT、支持CUDA的PyTorch， CUDA-enabled TensorFlow和NVIDIA GPU上的JAX-neneneba XLA。
• Apple Silicon应该更喜欢本地macOS工人、Homebrew或系统依赖、Python虚拟 环境，以及苹果原生加速层，如Metal、Core ML、JAX Metal和PyTorch 议员。仅支持Docker和VM对于苹果来说是不够的。

计划中的默认发动机选项包括：

这些ANN支持路径的操作说明：

• Whisper：Linux路径应针对吞吐量和可查询的服务器推理进行优化，而 Apple路径应针对离线本地执行和低摩擦本地安装进行优化。
• Demucs 和 Open-Unmix：将它们保存在隔离的GPU工作类中，因为源代码分离 与语音转录有实质性不同的记忆和批处理行为。
• Basic Pitch：保持TensorFlow和非TensorFlow序列化可用，但处理 CUDA上的TensorFlow和Apple上的Core ML作为默认生产通道。
• MT3：将JAX视为规范执行模型，并保持Apple Metal路径处于活动状态 一致性测试，因为JAX-Metal支持比CUDA更年轻。
• Omnizart：不要将当前上游ARM macOS不兼容视为可接受的。头等舱 Apple支持意味着我们拥有本机运行它所需的模型导出和执行路径。
• Audiveris：尽管Audiveris在内部为某些符号类使用了神经网络，但它 应被视为一个集成的JVM OMR应用程序，而不是一个单独管理的ANN 模型运行时。

未来堆栈中的非ANN工具，例如 ffmpeg, sox, rubberband, fluidsynth, music21, lilypond, OpenSheetMusicDisplay, MuseScore, Essentia，以及 Sonic Annotator, 仍然很重要，但它们不需要相同的推理引擎矩阵。

未来自由和开源软件工具目标

未来的工作流程扩展预计将增加或深化与以下方面的集成：

• whisper.cpp 用于母语语音转录
• faster-whisper 和 CTranslate2 用于在NVIDIA GPU上进行高通量Whisper推理
• Demucs 和 Open-Unmix 用于源分离
• Basic Pitch, MT3，以及 Omnizart 用于自动音乐转录
• music21 用于符号转换和排列
• LilyPond, MuseScore，以及 OpenSheetMusicDisplay 用于表示、转换、渲染和浏览器预览
• Audiveris 用于光学音乐识别
• Essentia 和 Sonic Annotator 用于MIR提取和分析

发展路线图

权威的实施计划存在于 开发计划/自述.md路线图分为概述、系统组件清单、每个阶段的文档和清理分类账。第1-24阶段现在已针对当前的存储库范围关闭，包括仅组合工作流、扩展的边界工具库存、修复的外部容器Whisper运行时、模型和夹具基础设施、适配器验证器、示例DAG链、合成混沌覆盖、SES电子邮件界面和受管工具文档。基于重定向的OAuth/PKCE仍然被故意推迟。

状态/当前到期日

当前状态：

• 存储库政策和开发计划已经到位。
• 这 documents/ 套件现在有一个明确的标准SSoT和索引。
• Kubernetes正向仓库脚手架已经到位：一个Dockerfile、一个Helm chart、Skaffold配置和kind配置。
• 无脚本策略、外部开发容器模型和本地存储原则现在已被记录并实质性地体现在代码中。
• 当前的路线图实质上是在支持的路径上实现的：运行时、身份验证、控制平面契约、浏览器会话契约、集群奇偶校验、领域引导自动化、注册表映像流、CLI管理的秘密、构建工件隔离和最终回归门都已关闭。
• 这 studiomcp CLI现在包括本机 test, test unit, test integration, test seed-fixtures, test verify-fixtures, test chaos, models sync, models list, models verify, email send-test, validate all, dag validate ..., dag validate-fixtures, validate docs, validate cluster, validate pulsar, validate minio, validate boundary, validate ffmpeg-adapter, validate sox-adapter, validate demucs-adapter, validate whisper-adapter, validate basic-pitch-adapter, validate fluidsynth-adapter, validate rubberband-adapter, validate imagemagick-adapter, validate mediainfo-adapter, validate executor, validate e2e, validate worker, validate inference, validate mcp-stdio, validate mcp-http, validate mcp-conformance, validate keycloak, validate mcp-auth, validate session-store, validate horizontal-scale, validate web-bff，以及 cluster ... 命令，加 studiomcp bff。参见 documents/reference/cli_reference.md 以获取完整的CLI参考。
• docker-compose.yaml 现在推出临时外层 studiomcp 开发容器；所有应用程序服务都在该类集群中运行。
• 一个真正的Haskell MinIO适配器现在通过部署的MinIO sidecar来回传输备忘录对象、清单和摘要，并将缺失的对象查找映射到稳定的存储故障契约。
• 实边界运行时现在执行确定性辅助进程，包括stdout/stderr捕获、非零退出投影和强制超时失败映射，以及 studiomcp validate boundary 行使该合同。
• 真正的FFmpeg适配器现在运行在边界运行时之上，在 examples/assets/audio/，验证一个成功的转码，并为丢失的输入断言结构化故障输出。
• 服务器、推理、worker和BFF入口点都是具有验证覆盖的真实运行时，包括实时Keycloak支持的身份验证、浏览器会话和nginx边缘路径。
• 已验证的命令现在包括 docker compose run --rm studiomcp cabal --builddir=/opt/build/studiomcp build all, docker compose run --rm studiomcp studiomcp test, docker compose run --rm studiomcp studiomcp validate docs, docker compose config、集群验证系列、MCP验证系列(validate mcp-stdio, validate mcp-http, validate mcp-conformance)，身份验证/会话验证系列(validate keycloak, validate mcp-auth, validate session-store, validate horizontal-scale, validate web-bff)，新的边界验证器系列(validate sox-adapter, validate demucs-adapter, validate whisper-adapter, validate basic-pitch-adapter, validate fluidsynth-adapter, validate rubberband-adapter, validate imagemagick-adapter, validate mediainfo-adapter)，加 helm lint, helm template, skaffold diagnose，以及 skaffold render。当前套件计数和最新聚合验证结果在中跟踪 开发计划/自述.md.
• 现在已在此计算机上验证了基本的外部容器群集工作流。已发货 values-kind.yaml 为有状态的sidecar使用手动主机支持的持久卷，以及 cluster storage reconcile 在Helm部署之前应用这些PV。

贡献指导

该仓库将文档、架构说明和测试视为一级工件。按照套房索引 文档/README.md 以及文件规则 文档/文档_标准.md.LLM代理可以编辑文件并运行本地验证，但提交和推送是为人类用户保留的。看 代理商.md 和 CLAUDE.md.