Super Dev 2.6.0

Super Dev 2.6.0

状态：已于 2026-09-18 正式发布。

版本定位

2.6.0 是可靠性收敛版本，不扩建新的 Agent 平台能力。目标是让 Super Dev 始终准确回答：当前工作项是什么、做到哪一步、针对哪版代码、哪些验证仍有效，以及是否真正发布。

主要变化

• workflow-state.json 成为唯一当前流程状态；
• 状态写入具备修订冲突、跨平台锁、原子替换、历史快照和恢复基础；
• SESSION_BRIEF.md 根据最新状态自动生成；
• pipeline-state.json 一次迁移后删除，不再生成；
• 引擎阶段进度和专家证据进入统一状态与阶段记录；
• 关键验证绑定工作项和当前代码版本；
• Fresh Verification 长时运行改为受控文件收集输出，每分钟显示心跳，并在正常结束、超时或取消后确认残留子进程已清理；可按测试目标隔离 pytest 进程，保持原测试范围、同一总时限和单一候选证据；
• 正式发布成功后记录独立 released 事实，不推导 deployed/operating；
• 包、配置、Skill、文档和构建制品版本统一为 2.6.0。

明确不包含

• 新阶段或影子账本控制权；
• Agent Runtime、多代理调度或多项目 Fleet；
• Memory 2.0、Engineering OS、通用插件市场；
• UI 页面、Dashboard、SBOM 或供应链签名平台。

发布前要求

本次正式发布已完成定向与全量测试、Windows/Linux 验证、质量门、Fresh Verification、Release Readiness、Proof Pack、构建与制品元数据检查。

安装或升级

uv tool install --force --from "git+https://github.com/mixyoung/super-dev.git@v2.6.0" super-dev

Super Dev 2.5.1

Super Dev 2.5.1

日期：2026-09-16。状态：GitHub-only 正式版本。

本次更新

• 修正任务定位：完整提示、单任务和待办读取明确活动变更，不以创建时间或“仅剩一项”代替任务关联。
• 修正恢复指导：读取既有状态与产物绑定确认，保留已完成任务，不固定重回 research、frontend 或任务 1.1。
• 明确只读请求不授权修改或阶段推进；标准有 UI 工作等待预览确认，无 UI 沿用不适用处理。
• 对齐知识要求：无显式适用条件时默认强制；带条件的按条件适用并说明依据，不由模型任意降低标准。
• 清理模板额外增加的通用义务，保留配置与现有默认质量要求；公共接口按消费者验证，不因本仓库未调用而直接删除。
• 框架提示尊重现有架构和本次范围，专家清单保留方法的可选性与原文适用条件。
• 修复常规 QA 被 VERIFICATION 变体覆盖、已加载专家未进入提示以及引号解析损坏；同步已有专家定义、手册和标准 Skill。
• 增加内容权威层级、知识信封和确定性控制守卫，仓库及外部指令不能改变权限、确认、阶段或发布决定。
• 收敛专家阶段真源与工作合同，补齐不同会话只读复审的候选/版本/文件摘要见证。
• 增加标准流程工作项身份、文档摘要绑定与原子状态写入，避免恢复时串入旧 change 或旧证据。
• 解耦交付、发布、部署和运营事实；候选摘要不再受用户本地配置或机器级 Git ignore 影响。
• 修正研究路线图被误判为当前范围缺口的问题，同时保留未完成任务与 unknown 的真实状态。

验证与范围

早期八类修正的关联回归为 957 项通过、2 项既有跳过；本轮框架维护的最终 fresh-verification 为 388 项收集、386 项执行、2 项跳过、0 失败/错误。Ruff、Black、Mypy、compileall、贡献范围与 Skill 同步通过；MiniMax-M3 与 DeepSeek-v4-flash 的最终只读差异复审均为 PASS。Quality Gate 为 90.6/90，Release Readiness 为 100/85，Proof Pack 为 35/35。

本次更新程序包、品牌显示、Skill、锁文件，以及按现有约定随软件版本变化的新建配置、文档和打包默认值。用户已生成的历史产物、自定义项目版本、配置迁移基线、可选插件包独立版本及第三方依赖版本不作全局替换。SEEAI 仅随软件更新版本元数据，比赛流程、文案与模拟数据设定不变。

不新增状态机或规则引擎，不改默认质量阈值，不让产品自动维护自己的知识库。其他用户项目的历史产物及全局安装不会自动被修改。

安装与发布边界

本次发行创建 v2.5.1 标签，并在 mixyoung/super-dev GitHub Release 发布 wheel、sdist 与 SHA256SUMS.txt。不上传 PyPI，不执行部署；released 仅指本 fork 的 GitHub Release，不推导为已部署或已运营。

uv tool install --force --from "git+https://github.com/mixyoung/super-dev.git@v2.5.1" super-dev

Super Dev 2.5.0

Super Dev 2.5.0

发布日期：2026-09-07。发布仓库：mixyoung/super-dev；这是本 fork 的 GitHub 发行版，不是原作者的 PyPI 发布。

保持不变

Super Dev 仍是宿主内的开发治理与知识工具。宿主负责模型、编辑和执行；标准九阶段、文档/预览确认、SEEAI 差异与原质量阈值保持。没有把它改造成 UmaDev 式独立专用程序。

自 v2.4.0 起的主要变化

• 流程与范围：结构化范围声明、阶段建议和只读影子台账，用于审计与比较；不代替用户批准，不推进真实流程。
• 完成前验证与扩展：来源锁、权限、结构化执行器、证据、所有权、路径守卫；当前代码版本的测试结果与整个项目可交付状态分开。
• 知识和方法：按问题吸收 Forge、需求审查、Grill、调试/TDD 与 UmaDev 的文档/代码/模板理念。贡献准则、来源取舍和验证记录固定在仓库，不靠模型自行改变演进方向。
• 跨平台可靠性：Windows 用户目录隔离、进程树清理、UTF-8 报告、路径规范、日志释放、Git Bash 识别；UI 契约非法文件名修复，普通路径与显示名称保留。
• 一致性与性能：类型/输入边界收敛；知识索引绑定目标项目，规则解析按内容缓存并深拷贝，文件变化失效。宿主项目必需与用户可选接入分开判断。
• 安全与贡献门禁：升级七个已知公告依赖的安全下限；安全命令不吞错。Linux 类型/测试与 Windows 单元矩阵纳入实际验证，main 保留八项必过检查。
• 发行制品资源：补齐 wheel/sdist 中既有的验证规则、设计 CSV、文档模板和 Web 静态入口，避免源码环境正常而安装后缺资源；未新增规则内容。

安装与升级

Python 3.10+，需要 uv 和 Git：

uv tool install --force --from "git+https://github.com/mixyoung/super-dev.git@v2.5.0" super-dev
super-dev --version

也可下载本 Release 的 wheel，用 uv tool install --force ./super_dev-2.5.0-py3-none-any.whl 安装。安装后照旧运行 super-dev 进行项目级接入，再回宿主使用对应 Skill。

不要运行 pip install super-dev==2.5.0 来获取此 fork：没有上传 PyPI。原 super-dev update 保留其更新来源逻辑，后续更新此 fork 时请明确指定新的 GitHub 标签或 wheel。

验证与已知边界

以最终发布提交对应的验证附件和 CI 为准；开发分支的历史成绩不是发布成功证据。验收覆盖包版本一致、静态/类型检查、Linux 完整 tests/、Windows 单元矩阵、知识门禁、安全审计、性能原基准、隔离交付冒烟、实际宿主文件就绪、wheel/sdist 与隔离安装。

• Windows 完整单元与 Linux 完整测试分别报告，不声称所有 Windows 集成/端到端场景都已完整认证。本机包含运行环境的大工作区曾触发默认目录扫描超时；不作为通过结果。
• 原性能基准是预热后的重复初始化均值；冷启动、首次校验单列，不声称所有启动都低于 100ms。
• 交付 smoke 使用临时项目和模拟确认，只证明打包链路；实际宿主文件就绪不等于已完成所有宿主的真实开发会话认证。
• 只发布 Python wheel/sdist 和 Git 标签源码。可选插件增强包沿用独立版本，不在本次单独发布或认证；仓库内 Claude 可选插件旧清单存在历史格式问题，推荐使用 Python CLI 的项目级接入，不将该可选插件包视为本版已认证入口。
• 仓库内旧 completion-verification 开发任务的 quality/readiness/proof-pack 与确认状态没有被改写或冒充本次软件包验收。

回退

有问题时停止使用该版本，在隔离环境安装先前保留的可信 wheel 或本 fork 的旧标签。旧版本可能重新带回本版修复的漏洞，不应当作无风险长期方案；应在 GitHub Release 中明确问题并发布修订版本。不会删除/移动已有标签，也不会操作原作者 PyPI 项目。