open-webui/Fu-Jie_openwebui-extensions
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(github-copilot-sdk): release v0.10.0 with native prompt restoration and live todo widget

Browse Source 
- Restore native Copilot CLI prompts for authentic Plan Mode behavior
- Add SQLite-backed session management for state persistence via system prompt
- Implement Adaptive Autonomy (Agent chooses planning vs direct execution)
- Fix OpenWebUI custom tool context injection for v0.8.x compatibility
- Add compact Live TODO widget synchronized with session.db
- Upgrade SDK to github-copilot-sdk==0.1.30
- Remove legacy mode switch RPC calls (moved to prompt-driven orchestration)
- Fix intent status localization and widget whitespace optimization
- Sync bilingual READMEs and all documentation mirrors to v0.10.0
This commit is contained in:
fujie
2026-03-07 04:30:15 +08:00
parent 35dec491de
commit f5a983fb4a
44 changed files with 5993 additions and 489 deletions
Download Patch File Download Diff File Expand all files Collapse all files

426
docs/development/gh-aw-integration-plan.md Normal file
View File

@@ -0,0 +1,426 @@
# gh-aw Integration Plan
> This document proposes a safe, incremental adoption plan for GitHub Agentic Workflows (`gh-aw`) in the `openwebui-extensions` repository.
---
## 1. Goals
- Add repository-aware AI maintenance without replacing stable script-based CI.
- Use `gh-aw` where natural language reasoning is stronger than deterministic shell logic.
- Preserve the current release, deploy, publish, and stats workflows as the execution backbone.
- Introduce observability, diagnosis, and long-term maintenance memory for repository operations.
---
## 2. Why gh-aw Fits This Repository
This repository already has strong deterministic automation:
- `/.github/workflows/release.yml`
- `/.github/workflows/plugin-version-check.yml`
- `/.github/workflows/deploy.yml`
- `/.github/workflows/publish_plugin.yml`
- `/.github/workflows/community-stats.yml`
Those workflows are good at exact execution, but they do not deeply understand repository policy.
`gh-aw` is a good fit for tasks that require:
- reading code, docs, and PR descriptions together
- applying repository conventions with nuance
- generating structured review comments
- diagnosing failed workflow runs
- keeping long-term maintenance notes across runs
This matches the repository's real needs:
- bilingual documentation synchronization
- plugin code + README + docs consistency
- release-prep validation across many files
- issue and PR maintenance at scale
---
## 3. Non-Goals
The first adoption phase should not:
- replace `release.yml`
- replace `publish_plugin.yml`
- replace MkDocs deployment
- auto-merge or auto-push code changes by default
- grant broad write permissions to the agent
`gh-aw` should begin as a review, diagnosis, and preflight layer.
---
## 4. Adoption Principles
### 4.1 Keep deterministic workflows for execution
Existing YAML workflows remain responsible for:
- release creation
- plugin publishing
- documentation deployment
- version extraction and comparison
- stats generation
### 4.2 Add agentic workflows for judgment
`gh-aw` workflows should focus on:
- policy-aware review
- release readiness checks
- docs drift analysis
- CI failure investigation
- issue triage and response drafting
### 4.3 Default to read-only behavior
Start with minimal permissions and use safe outputs only for controlled comments or issue creation.
### 4.4 Keep the blast radius small
Roll out one workflow at a time, verify output quality, then expand.
---
## 5. Proposed Repository Layout
### 5.1 New files and directories
```text
.github/
├── workflows/
│ ├── release.yml
│ ├── plugin-version-check.yml
│ ├── deploy.yml
│ ├── publish_plugin.yml
│ ├── community-stats.yml
│ ├── aw-pr-maintainer-review.md
│ ├── aw-pr-maintainer-review.lock.yml
│ ├── aw-release-preflight.md
│ ├── aw-release-preflight.lock.yml
│ ├── aw-ci-audit.md
│ ├── aw-ci-audit.lock.yml
│ ├── aw-docs-drift-review.md
│ └── aw-docs-drift-review.lock.yml
├── gh-aw/
│ ├── prompts/
│ │ ├── pr-review-policy.md
│ │ ├── release-preflight-policy.md
│ │ ├── ci-audit-policy.md
│ │ └── docs-drift-policy.md
│ ├── schemas/
│ │ └── review-output-example.json
│ └── README.md
└── copilot-instructions.md
```
### 5.2 Naming convention
Use an `aw-` prefix for all agentic workflow source files:
- `aw-pr-maintainer-review.md`
- `aw-release-preflight.md`
- `aw-ci-audit.md`
- `aw-docs-drift-review.md`
Reasons:
- clearly separates agentic workflows from existing handwritten YAML workflows
- keeps `gh-aw` assets easy to search
- avoids ambiguity during debugging and release review
### 5.3 Why not replace `.yml` files
The current workflows are production logic. `gh-aw` should complement them first, not absorb their responsibility.
---
## 6. Recommended Workflow Portfolio
### 6.1 Phase 1: PR Maintainer Review
**File**: `/.github/workflows/aw-pr-maintainer-review.md`
**Purpose**:
- review PRs that touch plugins, docs, or development guidance
- comment on missing repository-standard updates
- act as a semantic layer on top of `plugin-version-check.yml`
**Checks to perform**:
- plugin version updated when code changes
- `README.md` and `README_CN.md` both updated when required
- docs mirror pages updated when required
- root README badge/date update needed for release-related changes
- i18n and helper-method standards followed for plugin code
- Conventional Commit quality in PR title/body if relevant
**Suggested permissions**:
```yaml
permissions:
contents: read
pull-requests: write
issues: write
```
**Suggested tools**:
- `github:` read-focused issue/PR/repo tools
- `bash:` limited read commands only
- `edit:` disabled in early phase
- `agentic-workflows:` optional only after adoption matures
### 6.2 Phase 1: Release Preflight
**File**: `/.github/workflows/aw-release-preflight.md`
**Purpose**:
- run before release or on manual dispatch
- verify release completeness before `release.yml` does packaging and publishing
**Checks to perform**:
- code version and docs versions are aligned
- bilingual README updates exist
- docs plugin mirrors exist and match the release target
- release notes sources exist where expected
- commit message and release draft are coherent
**Output style**:
- summary comment on PR or issue
- optional checklist artifact
- no direct release creation
### 6.3 Phase 2: CI Audit
**File**: `/.github/workflows/aw-ci-audit.md`
**Purpose**:
- inspect failed runs of `release.yml`, `publish_plugin.yml`, `community-stats.yml`, and other important workflows
- summarize likely root cause and next fix steps
**Why gh-aw is strong here**:
- it can use `logs` and `audit` via `gh aw mcp-server`
- it is designed for workflow introspection and post-hoc analysis
### 6.4 Phase 2: Docs Drift Review
**File**: `/.github/workflows/aw-docs-drift-review.md`
**Purpose**:
- periodically inspect whether plugin code, local README files, mirrored docs, and root indexes have drifted apart
**Checks to perform**:
- missing `README_CN.md`
- README sections out of order
- docs page missing after plugin update
- version mismatches across code and docs
### 6.5 Phase 3: Issue Maintainer
**Candidate file**: `/.github/workflows/aw-issue-maintainer.md`
**Purpose**:
- summarize unreplied issues
- propose bilingual responses
- group repeated bug reports by plugin
This should come after the earlier review and audit flows are trusted.
---
## 7. Mapping to Existing Workflows
| Current Workflow | Keep As-Is | gh-aw Companion | Role Split |
|------|------|------|------|
| `/.github/workflows/release.yml` | Yes | `aw-release-preflight.md` | `release.yml` executes; `gh-aw` judges readiness |
| `/.github/workflows/plugin-version-check.yml` | Yes | `aw-pr-maintainer-review.md` | hard gate + semantic review |
| `/.github/workflows/deploy.yml` | Yes | none initially | deterministic build and deploy |
| `/.github/workflows/publish_plugin.yml` | Yes | `aw-ci-audit.md` | deterministic publish + failure diagnosis |
| `/.github/workflows/community-stats.yml` | Yes | `aw-ci-audit.md` | deterministic stats + anomaly diagnosis |
---
## 8. Tooling Model
### 8.1 Built-in tools to enable first
For early workflows, prefer a narrow tool set:
```yaml
tools:
github:
toolsets: [default]
bash:
- echo
- pwd
- ls
- cat
- head
- tail
- grep
- wc
- git status
- git diff
```
Do not enable unrestricted shell access in phase 1.
### 8.2 MCP usage model
Use `gh aw mcp-server` later for:
- workflow `status`
- workflow `compile`
- workflow `logs`
- workflow `audit`
- `mcp-inspect`
This is especially valuable for `aw-ci-audit.md`.
### 8.3 Safe output policy
In early adoption, only allow safe outputs that:
- comment on PRs
- comment on issues
- open a low-risk maintenance issue when explicitly needed
Avoid any automatic code-writing safe outputs at first.
---
## 9. Repo Memory Strategy
`gh-aw` repo memory is a strong fit for this repository, but it should be constrained.
### 9.1 Recommended first use cases
- recurring CI failure signatures
- repeated docs sync omissions
- common reviewer reminders
- issue clusters by plugin name
### 9.2 Recommended configuration shape
- store only `.md` and `.json`
- small patch size limit
- one memory stream per concern
Suggested conceptual layout:
```text
memory/review-notes/*.md
memory/ci-patterns/*.md
memory/issue-clusters/*.json
```
### 9.3 Important caution
Do not store secrets, tokens, or unpublished sensitive data in repo memory.
---
## 10. Rollout Plan
### Phase 0: Preparation
- install `gh-aw` locally for maintainers
- add a short `/.github/gh-aw/README.md`
- document workflow naming and review expectations
### Phase 1: Read-only semantic review
- introduce `aw-pr-maintainer-review.md`
- introduce `aw-release-preflight.md`
- keep outputs limited to summaries and comments
### Phase 2: Diagnostics and memory
- introduce `aw-ci-audit.md`
- enable `agentic-workflows:` where useful
- add constrained `repo-memory` configuration for repeated failure patterns
### Phase 3: Maintenance automation
- add docs drift patrol
- add issue maintenance workflow
- consider limited code-change proposals only after trust is established
---
## 11. Local Maintainer Setup
For local experimentation and debugging:
### 11.1 Install CLI
```bash
curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash
```
### 11.2 Useful commands
```bash
gh aw version
gh aw compile
gh aw status
gh aw run aw-pr-maintainer-review
gh aw logs
gh aw audit <run-id>
```
### 11.3 VS Code MCP integration
A future optional improvement is adding `gh aw mcp-server` to local MCP configuration so workflow introspection tools are available in editor-based agent sessions.
---
## 12. Recommended First Deliverables
Start with these two workflows only:
1. `aw-pr-maintainer-review.md`
2. `aw-release-preflight.md`
This gives the repository the highest-value upgrade with the lowest operational risk.
---
## 13. Success Criteria
Adoption is working if:
- PR review comments become more specific and repository-aware
- release preparation catches missing docs or version sync earlier
- CI failures produce actionable summaries faster
- maintainers spend less time on repetitive policy review
- deterministic workflows remain stable and unchanged in core behavior
---
## 14. Summary
For `openwebui-extensions`, `gh-aw` should be adopted as an intelligent maintenance layer.
- Keep current YAML workflows for execution.
- Add agentic workflows for policy-aware review and diagnosis.
- Start read-only.
- Expand only after signal quality is proven.
This approach aligns with the repository's existing strengths: strong conventions, bilingual maintenance, plugin lifecycle complexity, and growing repository operations.

424
docs/development/gh-aw-integration-plan.zh.md Normal file
View File

@@ -0,0 +1,424 @@
# gh-aw 集成方案
> 本文档用于为 `openwebui-extensions` 仓库设计一套安全、渐进式的 GitHub Agentic Workflows (`gh-aw`) 接入方案。
---
## 1. 目标
- 在不替换现有稳定 CI 的前提下，引入具备仓库理解能力的 AI 维护层。
- 将 `gh-aw` 用于更适合自然语言推理的任务，而不是机械脚本执行。
- 保留当前发布、部署、发布插件和统计工作流作为执行骨架。
- 为仓库维护引入可观测性、自动诊断和长期记忆能力。
---
## 2. 为什么这个仓库适合 gh-aw
本仓库已经有一套很强的确定性自动化：
- `/.github/workflows/release.yml`
- `/.github/workflows/plugin-version-check.yml`
- `/.github/workflows/deploy.yml`
- `/.github/workflows/publish_plugin.yml`
- `/.github/workflows/community-stats.yml`
这些工作流擅长精确执行，但并不擅长理解仓库规范本身。
`gh-aw` 更适合以下任务：
- 联合阅读代码、文档和 PR 描述后再做判断
- 带语义地应用仓库规范
- 生成结构化的 review 评论
- 自动分析失败的工作流运行
- 在多次运行之间保存维护经验和模式
这与当前仓库的真实需求高度匹配：
- 双语文档同步
- 插件代码、README 与 docs 一致性检查
- 跨多个文件的发布前完整性核查
- Issue 与 PR 的规模化维护
---
## 3. 非目标
第一阶段不建议让 `gh-aw`：
- 替换 `release.yml`
- 替换 `publish_plugin.yml`
- 替换 MkDocs 部署
- 默认自动合并或自动推送代码
- 一开始就拥有过宽的写权限
第一阶段应把它定位为 review、诊断和 preflight 层。
---
## 4. 接入原则
### 4.1 确定性执行继续由 YAML 工作流承担
现有 YAML workflow 继续负责：
- 创建 release
- 发布插件
- 部署文档
- 提取和比较版本号
- 生成社区统计
### 4.2 Agentic workflow 只负责判断和总结
`gh-aw` workflow 优先承担：
- 基于规范的语义审查
- 发布前完整性检查
- 文档漂移巡检
- CI 失败原因分析
- Issue 分流与回复草稿生成
### 4.3 默认只读
优先使用最小权限，并通过 safe outputs 进行受控评论或低风险输出。
### 4.4 逐步扩容
一次只上线一个 agentic workflow，验证质量后再扩大范围。
---
## 5. 建议的仓库结构
### 5.1 新增文件和目录
```text
.github/
├── workflows/
│ ├── release.yml
│ ├── plugin-version-check.yml
│ ├── deploy.yml
│ ├── publish_plugin.yml
│ ├── community-stats.yml
│ ├── aw-pr-maintainer-review.md
│ ├── aw-pr-maintainer-review.lock.yml
│ ├── aw-release-preflight.md
│ ├── aw-release-preflight.lock.yml
│ ├── aw-ci-audit.md
│ ├── aw-ci-audit.lock.yml
│ ├── aw-docs-drift-review.md
│ └── aw-docs-drift-review.lock.yml
├── gh-aw/
│ ├── prompts/
│ │ ├── pr-review-policy.md
│ │ ├── release-preflight-policy.md
│ │ ├── ci-audit-policy.md
│ │ └── docs-drift-policy.md
│ ├── schemas/
│ │ └── review-output-example.json
│ └── README.md
└── copilot-instructions.md
```
### 5.2 命名规范
所有 agentic workflow 源文件统一使用 `aw-` 前缀：
- `aw-pr-maintainer-review.md`
- `aw-release-preflight.md`
- `aw-ci-audit.md`
- `aw-docs-drift-review.md`
这样做的原因：
- 可以和现有手写 YAML 工作流明确区分
- 便于在仓库中快速搜索和定位
- 方便调试和发布时识别来源
### 5.3 为什么不直接替换 `.yml`
当前 `.yml` 文件承担的是生产执行逻辑。第一阶段 `gh-aw` 的角色应该是补充，而不是接管。
---
## 6. 建议优先建设的 workflow 组合
### 6.1 第一阶段：PR 维护者语义审查
**文件**: `/.github/workflows/aw-pr-maintainer-review.md`
**作用**:
- 审查涉及插件、文档或开发规范的 PR
- 对缺失的仓库标准更新给出评论
- 作为 `plugin-version-check.yml` 之上的语义层
**建议检查项**:
- 插件代码修改后是否更新版本号
- 是否同时更新 `README.md` 和 `README_CN.md`
- 是否同步更新 docs 镜像页
- 是否需要更新根 README 的日期 badge
- 插件代码是否遵守 i18n 与 helper 规范
- PR 标题或正文是否符合 Conventional Commits 精神
**建议权限**:
```yaml
permissions:
contents: read
pull-requests: write
issues: write
```
**建议工具**:
- 只读型 `github:` 工具
- 只开放少量只读 `bash:` 命令
- 第一阶段不开放 `edit:`
- `agentic-workflows:` 可在后续成熟后再启用
### 6.2 第一阶段：发布前预检
**文件**: `/.github/workflows/aw-release-preflight.md`
**作用**:
- 在 release 前或手动触发时执行
- 在 `release.yml` 打包和发布之前，先检查发布完整性
**建议检查项**:
- 代码版本号和文档版本号是否一致
- 双语 README 是否完整更新
- docs 插件镜像页是否存在并匹配当前发布目标
- release notes 来源文件是否齐全
- commit message 与 release 草案是否连贯
**输出方式**:
- 在 PR 或 issue 中写总结评论
- 可附带 checklist artifact
- 不直接执行正式发布
### 6.3 第二阶段：CI 失败自动审计
**文件**: `/.github/workflows/aw-ci-audit.md`
**作用**:
- 分析 `release.yml`、`publish_plugin.yml`、`community-stats.yml` 等关键 workflow 的失败运行
- 输出根因判断和下一步修复建议
**适合 gh-aw 的原因**:
- 可以通过 `gh aw mcp-server` 使用 `logs`、`audit` 等能力
- 原生支持对 workflow 执行痕迹进行事后分析
### 6.4 第二阶段：文档漂移巡检
**文件**: `/.github/workflows/aw-docs-drift-review.md`
**作用**:
- 定期检查插件代码、插件目录 README、本地 docs 镜像和根索引之间是否发生漂移
**建议检查项**:
- 是否缺少 `README_CN.md`
- README 章节顺序是否偏离规范
- 插件更新后 docs 页面是否缺失
- 代码和文档中的版本号是否不一致
### 6.5 第三阶段：Issue 维护助手
**候选文件**: `/.github/workflows/aw-issue-maintainer.md`
**作用**:
- 汇总长期未回复的 issue
- 生成英文或双语回复草稿
- 按插件归类重复问题
这个阶段建议在前面的 review 和 audit 流程稳定后再上线。
---
## 7. 与现有 workflow 的职责映射
| 当前 Workflow | 是否保留 | gh-aw 搭档 | 职责划分 |
|------|------|------|------|
| `/.github/workflows/release.yml` | 保留 | `aw-release-preflight.md` | `release.yml` 负责执行，`gh-aw` 负责判断是否已准备好 |
| `/.github/workflows/plugin-version-check.yml` | 保留 | `aw-pr-maintainer-review.md` | 硬性门禁 + 语义审查 |
| `/.github/workflows/deploy.yml` | 保留 | 初期不加 | 确定性构建和部署 |
| `/.github/workflows/publish_plugin.yml` | 保留 | `aw-ci-audit.md` | 确定性发布 + 失败诊断 |
| `/.github/workflows/community-stats.yml` | 保留 | `aw-ci-audit.md` | 确定性统计 + 异常诊断 |
---
## 8. 工具模型建议
### 8.1 第一阶段建议启用的内建工具
建议从窄权限工具集开始：
```yaml
tools:
github:
toolsets: [default]
bash:
- echo
- pwd
- ls
- cat
- head
- tail
- grep
- wc
- git status
- git diff
```
第一阶段不要开放完全不受限的 shell。
### 8.2 MCP 使用策略
后续可通过 `gh aw mcp-server` 引入：
- workflow `status`
- workflow `compile`
- workflow `logs`
- workflow `audit`
- `mcp-inspect`
这对 `aw-ci-audit.md` 特别有价值。
### 8.3 Safe output 策略
第一阶段仅开放低风险 safe outputs：
- 给 PR 写评论
- 给 issue 写评论
- 在明确需要时创建低风险维护 issue
一开始不要让 agent 自动提交代码修改。
---
## 9. Repo Memory 策略
`gh-aw` 的 repo memory 很适合本仓库，但必须加限制。
### 9.1 第一批适合保存的内容
- 重复出现的 CI 失败模式
- 常见文档同步遗漏
- 高频 review 提醒项
- 按插件聚类的 issue 模式
### 9.2 推荐配置思路
- 只允许 `.md` 和 `.json`
- 限制 patch size
- 按主题拆成多个 memory stream
建议的逻辑布局：
```text
memory/review-notes/*.md
memory/ci-patterns/*.md
memory/issue-clusters/*.json
```
### 9.3 重要提醒
不要把 secret、token 或未公开敏感信息写入 repo memory。
---
## 10. 分阶段落地顺序
### Phase 0: 准备阶段
- 维护者本地安装 `gh-aw`
- 添加一个简短的 `/.github/gh-aw/README.md`
- 写清楚 workflow 命名规范和 review 预期
### Phase 1: 只读语义审查
- 上线 `aw-pr-maintainer-review.md`
- 上线 `aw-release-preflight.md`
- 输出先限制为总结和评论
### Phase 2: 诊断与记忆
- 上线 `aw-ci-audit.md`
- 在需要的地方启用 `agentic-workflows:`
- 为重复失败模式加入受限 `repo-memory`
### Phase 3: 维护自动化
- 增加文档漂移巡检
- 增加 issue 维护 workflow
- 只有在信号质量足够稳定后，再考虑有限度的代码修改建议
---
## 11. 维护者本地使用建议
### 11.1 安装 CLI
```bash
curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash
```
### 11.2 常用命令
```bash
gh aw version
gh aw compile
gh aw status
gh aw run aw-pr-maintainer-review
gh aw logs
gh aw audit <run-id>
```
### 11.3 VS Code MCP 集成
后续可选增强项是把 `gh aw mcp-server` 加入本地 MCP 配置，这样编辑器内的 agent 会直接具备 workflow 自省能力。
---
## 12. 最小可行落地建议
建议第一步只做这两个 workflow：
1. `aw-pr-maintainer-review.md`
2. `aw-release-preflight.md`
这样可以以最低风险获得最高价值的增强。
---
## 13. 成功标准
如果接入有效，应该看到这些结果：
- PR 评论更具体，更贴合仓库规范
- 发布前能更早发现文档或版本同步遗漏
- CI 失败后更快得到可执行的总结
- 维护者花在重复性规范检查上的时间下降
- 现有确定性 workflow 的核心行为保持稳定
---
## 14. 总结
对 `openwebui-extensions` 来说，`gh-aw` 最合适的定位是智能维护层。
- 现有 YAML workflow 继续负责执行。
- agentic workflow 负责语义审查和诊断。
- 第一阶段默认只读。
- 等输出质量稳定后再逐步放权。
这条路径和仓库现状是匹配的：规范密度高、双语维护复杂、插件生命周期长，而且已经具备成熟的 AI 工程上下文。

BIN
docs/development/image.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 406 KiB

8
docs/development/index.md
View File

@@ -32,6 +32,14 @@ Learn how to develop plugins and contribute to OpenWebUI Extensions.
[:octicons-arrow-right-24: Read the Plan](copilot-engineering-plan.md)
- :material-source-branch:{ .lg .middle } **gh-aw Integration Plan**
---
Adoption plan for using GitHub Agentic Workflows as a semantic review and diagnostics layer in this repository.
[:octicons-arrow-right-24: Read the Plan](gh-aw-integration-plan.md)
- :material-github:{ .lg .middle } **Contributing**
---

8
docs/development/index.zh.md
View File

@@ -32,6 +32,14 @@
[:octicons-arrow-right-24: 阅读文档](copilot-engineering-plan.md)
- :material-source-branch:{ .lg .middle } **gh-aw 集成方案**
---
面向本仓库的 GitHub Agentic Workflows 渐进式接入设计，重点覆盖语义审查、发布预检与 CI 诊断。
[:octicons-arrow-right-24: 阅读文档](gh-aw-integration-plan.zh.md)
- :material-github:{ .lg .middle } **贡献指南**
---