Repository navigation
Releases: fengyincheng/patchpawwww
Release list
v0.3.0 — Docker 正式支持
🐳 Docker 部署
新增:
Dockerfilecompose.yaml- Docker healthcheck
- Docker 部署与升级文档
- GHCR 镜像发布流程
linux/amd64与linux/arm64多架构构建- native → Docker 迁移说明
PatchPaw 容器默认以非 root 用户运行,运行数据统一保存在:
/var/lib/patchpaw
Compose 使用持久化 volume 保存数据库、Memory、仓库缓存、worktree、run、snapshot、outbox 等运行数据。
🔐 更安全的容器默认配置
官方 Docker 配置默认:
- 使用非 root 用户运行
- 不挂载 Docker socket
- 不启用
privileged - 启用
no-new-privileges - GitHub App Private Key 通过只读挂载提供
- 使用 Tini 管理容器 PID 1
- 支持 SIGTERM 优雅停止
- 提供容器健康检查
🧰 支持扩展项目工具链
官方基础镜像只提供 PatchPaw 运行所需的基础环境:
- Node.js / npm
- Git
- CA certificates
- PatchPaw Web UI
Python、Java、Rust、Go、Android SDK、.NET 等项目环境不会全部塞进基础镜像。
如果目标仓库需要额外工具链,可以直接基于官方镜像构建自己的派生镜像:
FROM ghcr.io/fengyincheng/patchpaw:<version>
USER root
# 安装项目需要的工具链
USER patchpaw仓库中也新增了扩展镜像示例。
⚙️ 容器运行支持
为了支持容器部署,本版本同时调整了运行时配置:
.env不再是强制存在的启动文件- 支持通过环境变量直接注入配置
- 新增可配置监听地址
- native 部署仍默认监听
127.0.0.1 - Docker 内监听
0.0.0.0 tsx调整为正式运行依赖
已有 runtime 在 Docker 启动时仍会执行版本化 builtin migration。
该 migration 只会在 PatchPaw 服务正式启动时执行;backup、observer、shell 等运维命令不会因为启动 entrypoint 而隐式修改数据库。
📦 镜像发布
Docker 镜像通过 GitHub Container Registry 发布:
ghcr.io/fengyincheng/patchpaw
稳定 Release 将提供版本 tag,并同时构建:
linux/amd64
linux/arm64
生产环境建议固定具体版本,而不是长期依赖 latest
📖 文档
README 新增 Docker 快速开始,并新增完整的:
docs/DOCKER.md
其中包含:
- 从零部署
- 数据持久化
- Secret 管理
- 升级
- 备份
- 工具链扩展
- native → Docker 迁移
- Windows / macOS Docker Desktop 使用边界
v0.2.1 — 稳定性与生命周期修复
🐛 修复:修复 Multi-SCM 生命周期中 project_id 传递、通知持久化与失败恢复不完整的问题。
🤖 Agent 契约:修复 CI / Conflict 仍残留旧 structured completion 语义的问题,统一到当前自然语言输出契约。
🧪 测试:修复一批过时测试契约,并补回 workspace 创建后异常时必须清理的回归覆盖。
🛠️ 测试工具:改进串行测试器的分片、断点和 OOM / exit 137 处理,避免低内存环境下误判。
v0.2.0—重构与agent本地观察
👀 Agent Run 本地观察
新增只读 Agent Observer,可以直接在运行 PatchPaw 的机器上查看 Agent 当前在做什么。
npm run agent:open -- owner/repo 132
npm run agent:open -- --run --replay 20
npm run agent:status -- owner/repo 132
npm run agent:runs -- --failed --limit 50
agent:open 支持:
实时跟随 Agent Run
最近事件回放
--all
--replay N
--compact
--verbose
--json
--wait
同时完善了 Observer 的 Run 解析、等待/附着语义、摘要输出和失败状态展示。
🔀 GitHub / GitLab 统一执行核心
本版本对 Multi-SCM 架构进行了较大调整。
新增完整的:
GitHubAdapter implements ScmAdapter
GitLabAdapter implements ScmAdapter
原先独立维护大量业务逻辑的 GitLab Runner 已缩减为平台入口层,主要负责 GitLab connection、身份、snapshot 和上下文构造。
Task、Approval、Agent 执行、写回、恢复和结束流程不再分别维护两套实现。
🧩 Runner 架构重构
原先较为集中的 Runner 已拆分为更明确的生命周期模块,包括:
pull-request.ts 的职责显著收缩,平台差异进一步集中到 SCM Adapter 与入口层。
这也意味着以后新增共享功能时,不再需要分别给 GitHub 和 GitLab 维护两套生命周期实现。
✅ 新增更细的权限分级——读写(需审批)可在前端web调整
完善并统一了 read_write_approval 的执行流程:
Planning
→ 发布 Plan
→ 等待 /approval
→ 校验审批来源与当前 SCM 状态
→ Approved Write
→ Harness 写回
→ Settlement
✍️ 统一 Writeback
GitHub / GitLab 的写回流程已经收敛为共享实现。
如果 Agent 已经创建 commit,Harness 不会重复提交。
如果 Agent 只修改了工作区但没有 commit,Harness 会负责 commit。
📝 Agent 输出进一步自然语言化
新运行路径继续使用 opaque natural-language / Markdown 作为 Agent 输出。
Review、CI、Conflict、Custom、Repair 等任务不再依赖 Agent 输出固定业务 JSON 才能继续运行。
🧭 Control Plane 收敛
历史内置命令可以迁移到当前结构,同时尽量保留管理员已有的权限和自定义配置。
📬 Communication / Finalization 重构
任务执行完成与“用户是否真正收到消息”继续作为两个独立 durable fact 处理。
🛡️ 可靠性改进
本版本还包含多项运行时和恢复逻辑调整——Agent Turn lifecycle 更明确,Final-answer fallback 独立预算等。
升级说明
本版本主要是内部架构和可靠性升级,没有刻意改变现有命令的产品语义。
已有 GitHub / GitLab 用户可以继续使用原有配置。
新增 Agent Observer 命令可直接使用:
npm run agent:open -- owner/repo <PR/MR>
npm run agent:status -- owner/repo <PR/MR>
npm run agent:runs
v0.1.0 — GitLab 支持与可靠性更新
v0.1.0 — GitLab 支持与可靠性更新
这是 PatchPaw 的首个正式版本 Release。
本次版本重点完善了 GitLab 支持以及任务失败时的可观测性,让 GitLab MR 中的 Agent 执行结果和错误原因更加清晰、可靠。
GitLab
- 完善 GitLab Merge Request 工作流支持
- 支持 GitLab 自定义只读与读写命令
- 完善 GitLab Conflict、Review、Repair 等执行生命周期
- 增加 GitLab 配置与使用文档
错误处理与可观测性
- 细分 GitLab 失败类型:认证失败、配置错误、网络或上游服务不可用、协议/响应格式异常、请求被拒绝
- Provider 429、5xx 等上游错误现在会保留结构化错误信息
- MR 中会展示真实失败阶段,例如:阶段:repair;状态:provider_unavailable
- GitLab bootstrap 阶段失败也会持久化 Run、Trace 和 Result 信息
- 失败通知接入 durable outbox
- 通知发送失败不会覆盖原始任务错误
- 通知失败不会导致 Agent 或模型重复执行
- run_notice_published、run_notice_pending 和 run_notice_failed 现在能够反映真实通知状态
- GitHub 侧同步修正了通知 Trace 的状态语义
安全与依赖
- Vite 更新至 7.3.6
- 当前依赖审计未发现已知 npm 漏洞