v0.9.4

工程

• 本次没有产品代码改动：这个版本的作用是让新增的 PyPI 发布通道真实跑通一次 ——
  发布通道无法「演练」，只有真正发一个版本才知道 PyPI 侧的 OIDC 配置是否生效。
  → 普通用户不需要升级，功能与 0.9.3 完全一致。
• PyPI 接入 CI，走 OIDC 可信发布（不需要任何长期密钥）。 此前 PyPI 是手工发布的，
  代价是产物并非从干净检出构建：0.9.2 修好的 git+ URL 进了 PyPI 包、却没进 tag，
  同一个 tag 重新构建反而会被 PyPI 拒收。现在它与 Open VSX / Marketplace / npm 并列为
  第四个发布通道，同样排在创建 Release 之前（Release 是否存在仍是「该版本是否已发」
  的判据）。若 PyPI 侧未配置 Trusted Publisher，该 job 会直接失败而不是静默跳过 ——
  与 npm 通道同一取舍：显示成功却没发布，比失败更难查。
• CI 新增 Python 多版本测试（python-test job），覆盖 **3.10（requires-python 的
  下界）与 3.14（当前最新稳定）**两端：下界挡「误用更高版本才有的语法/标准库」，
  最新版挡「被移除的标准库」。测试用 pip install ./python 安装后再跑（顺带验证打包
  配置本身），并加一步冒烟断言 pyproject / 包内 __version__ / 命令行 --version
  三者一致 —— 0.9.3 修掉的正是这条单元测试覆盖不到的路径。

---

完整变更对比：v0.9.3...v0.9.4

---

发布通道

通道	本次结果
Open VSX	已发布 ✅
VS Code Marketplace	已发布 ✅
npm · npx @echo-note/gitea-toolkit-mcp	已发布 ✅
PyPI · uvx gitea-toolkit-mcp	已发布 ✅

v0.9.3

修复

• --version 与 MCP 的 serverInfo.version 报的是旧版本号（装着 0.9.2 却显示 0.9.1）。
  根因是包里还有第四份硬编码版本号：python/src/gitea_toolkit_mcp/__init__.py 里写着
  __version__ = "0.9.1"，注释还注明「由 scripts/bump-version.mjs 保持同步」——
  而那个脚本只改 package.json / npm 包 / pyproject.toml，根本不碰这个文件。
  现在改为从已安装分发包的元数据里读（importlib.metadata），这份副本直接删掉：
  少一份副本，就少一处「能忘记同步」的地方。

  抓到它的方式值得记下来：从 PyPI 真实装一遍再跑（uvx gitea-toolkit-mcp@0.9.2 --version），
  而不是只看构建产物的元数据 —— 元数据是对的，跑起来才是错的。

工程

• scripts/bump-version.mjs 补上 python/pyproject.toml 的同步。 该文件里本就写着
  「版本由本脚本同步」，实际并没有 —— 于是 PyPI 包会悄悄停在旧版本号上，而发布时
  没有任何机制会报错。
• npm run check:changelog 新增「三个发布物（扩展 / npm 包 / PyPI 包）版本号必须一致」。
  已反向验证：把 pyproject.toml 改回旧版本会立刻被拦下，并给出「跑 npm run version:patch
  会一起改」的提示。
• 补记一处首次发 PyPI 才暴露的坑：python/pyproject.toml 里的 Repository 原写成
  git+https://…/….git —— 那是 npm 的写法（npm 那边反而要求带 git+ 前缀），
  而 PyPI 的 core metadata 只认普通 URL，首次上传被 400 直接拒收。
  同一份仓库地址在两个生态里写法相反，已在文件里注明。

---

完整变更对比：v0.9.2...v0.9.3

---

发布通道

通道	本次结果
Open VSX	已发布 ✅
VS Code Marketplace	已发布 ✅
npm · npx @echo-note/gitea-toolkit-mcp	已发布 ✅

v0.9.2

为什么会有 0.9.2：0.9.1 是在 Python 版进仓库之前发出去的 —— 它只包含扩展与 npm 包，
npm 上的 0.9.1 里没有下面这些改动。本版把 Python 版 MCP 一并发布到 PyPI，
并让两个实现的行为与返回文本完全对齐（两个包共用同一版本号，是「同一次构建产出、
内容一致」的前提）。

新增

• Python 版 MCP 工具服务 gitea-toolkit-mcp（PyPI） —— 补齐到 35 个工具，
  与 TypeScript 版同名、同参数、同返回文本、同错误措辞，两个实现可互换：
  同一份提示词与客户端配置在任一实现下都能工作。

  工具名与参数名是按 TS 版的 inputShape 逐字对齐的（含 autoInit / filePath /
  deleteBranchAfterMerge 这类 camelCase，以及 Actions 域刻意保留的 run_id 等 snake_case），
  并有测试逐个断言 —— 两边的漂移会让「可互换」变成空话。

  实现中按实例的 /swagger.v1.json 核对出三处上游细节，值得记下来：

  • EditIssueOption 根本没有 labels 字段（10 个字段里确实没有）。也就是说
    把 labels 塞进 PATCH /issues/{index} 会被服务端静默忽略 —— 调用方以为改了标签、
    实际没改，而且不会报任何错。标签有专门的替换端点 PUT /issues/{index}/labels，
    两个实现都改走它（TS 侧原先也有这个问题，见「修复」）。
  • MergePullRequestOption 的字段全是小写蛇形（do / merge_title_field /
    merge_message_field），按 Go 结构体写成 Do 会因缺 do 被拒（服务端把 do 标为 required）。
  • /repos/issues/search 与 /notifications 的数组参数要展开成同名重复参数
    （status-types=unread&status-types=pinned），逗号拼接服务端不认。

• 两个 MCP 都会检查服务端 Gitea 版本，并把结论交给 AI 转达用户。

  MCP 里没有弹窗，唯一能到达模型的通道是工具返回。所以首次调用工具时自动读一次
  /version，判定不兼容就在返回开头插一段提示（开头写明「请转达给用户」，
  否则模型很容易只当背景信息），同一进程内只插一次；兼容时完全不插。
  两个实现都支持「仅本地可用」的用法，因此探测失败（网络不通、反代拦了 /version）
  只写 stderr 日志、绝不让工具调用失败。

  判定沿用扩展已有的那套（src/core/version.ts：已核对 1.26.4、最低支持 1.21.0，
  只比较主次版本，分 ok / newer / older / unsupported / unknown 五档），
  Python 侧按同一口径移植到 version.py，并有测试直接读 TS 源文件比对常量与措辞 ——
  同一台服务端换个实现就该得到同样的结论、同样的话。

  顺带：gitea_get_current_user（本就是「令牌 / 连通性自查」工具）的返回里始终带一行
  「服务端版本｜兼容性」，用户随时能复查。

• MCP 协议合规性修正（Python 版，逐条都有测试钉住）：

  • 必填参数真正进了 inputSchema.required。此前 35 个工具里只有 1 个声明了必填 ——
    因为参数写成 index: int = 0 再用运行时 raise 兜底，schema 于是宣称「什么都可以不传」，
    模型只能靠猜，且要等一次往返之后才拿得到报错。现在必填参数排在签名前面、不带默认值，
    与 TS 版的 zod 声明（没写 .optional() 就是必填）一致。
  • 工具报错终于能到达模型。MCP Python SDK v2 会把「非 ToolError 的异常」统一替换成
    Error executing tool <名字>（原始文案刻意不外泄）—— 结果是中文报错一个字都传不出去。
    现在统一在注册装饰器里包成 ToolError。
  • 每个工具都带 title（取自 TS 版 displayName，如「获取 Issue 详情」），
    tool.title 与 annotations.title 两处都写，与 TS 版一致。
  • destructiveHint 如实反映行为：原本所有写工具一律标破坏性，于是「创建 Issue」
    也会触发客户端的确认框 —— 用户很快会被训练成无脑点「同意」，真正危险的操作反而失去警示。
    现在分四档：只读 / 增量写（建 Issue、评论、提 PR、评审、触发与重跑工作流）/
    幂等写（标记通知已读）/ 破坏写（更新 Issue、覆盖文件、合并 PR、改工作流开关）。
  • 跨仓库检索的结果带上了仓库名：/repos/issues/search 的返回带 repository 字段，
    原先没利用 —— 「分配给我的 Issue」会返回一堆看不出属于哪个仓库的条目，模型无法跟进。

修复

• 修掉一个会让 Python 版完全连不上部分实例的坑：默认 User-Agent 从
  gitea-toolkit-mcp-python 改为 gitea-toolkit-mcp（与 TS 版一致）。
  起因是实测某实例的前置 nginx 按 UA 关键字拦截 —— UA 里只要出现 python
  （或干脆不发 UA）就直接 403 Forbidden，而那个 403 长得像权限问题，
  排查时极易被带偏。已加测试防止回退。

• 修掉两处「两个实现返回文本不一致」（都属于「可互换」承诺的破口）：

  • gitea_get_current_user：TS 版有「主页 / 注册时间」、Python 版有「实例」且用昵称当标题 ——
    同一份数据在两处输出成两个样子。现在统一为同一组字段（并为 TS 侧补上了实例地址，
    GiteaToolContext 新增 serverUrl）。
  • 相对时间：Python 版超过 30 天会退化成绝对日期、单位换算向下取整（90 秒说成「1 分钟前」）、
    未来时间说成「刚刚」、空值返回空串 —— TS 版则是永远相对表述（3 个月前）、
    四舍五入、未来用「后」、空值返回 -。已逐条对齐（含把 Python 的银行家舍入换成
    JS Math.round 的口径）。这两处都是跨语言比对测试抓出来的，不是看代码看出来的。

• gitea_update_issue 的「整体替换标签」其实一直没生效。 它把标签 ID 放进
  PATCH /repos/{o}/{r}/issues/{index} 的 body，但按实例 swagger 核对，那个接口的
  EditIssueOption 根本没有 labels 字段 —— 服务端静默忽略，既不报错也不生效。
  改为走专用端点 PUT /issues/{index}/labels（与 Python 版同一处理），并放在 PATCH
  之前发出，这样 PATCH 返回的实体里带的就是更新后的标签。
  只有 AI 工具这条路会传 labels（扩展自己的命令只传 {state}），所以其余行为不变。

• gitea_get_repo 在权限信息为空时会显示一个空荡荡的「- 权限：」。
  原代码是 f"- 权限：" + join(...) or "- 权限：（未知）" —— + 的优先级高于 or，
  而左边永远是非空字符串（至少含「- 权限：」），所以 or 那半边是死代码，
  兜底永远不会触发。

文档

• 根 README 补上「服务介绍」与「服务配置」两节（标题名就是平台提取用的字段名）。
  把本项目提交到 MCP 广场（魔搭 ModelScope 等）时，「从 GitHub 仓库快速创建」会从仓库根
  README 里按名字提取这两段，并把它们当强制校验字段 —— 解析不到就直接中断。
  README 里原本虽有 mcpServers 的 JSON，却没有任何标注，能否被提取完全看提取器的理解。
  新增 npm run check:mcp-manifest（已接进 npm run ci）守住：两节存在且非空、
  服务配置是合法 STDIO（command 只能是 npx / uvx、args 里要有包名且与真实包名一致、
  不得有本地绝对路径、JSON 不得带注释）、env 里有 GITEA_TOKEN。
  已用正反 8 个场景验证：正向通过；标题改名 / command 非法 / JSON 带注释 / 包名写错 /
  缺 env / 缺 json 代码块 / 塞本地绝对路径，各自都能拦住。

为什么这些文档修正值得单独发一个版本：npm 页面上的 README 与终端里的 --help
都只随发布更新 —— 0.9.0 的包页与已下载的 tarball 里仍是上述过时内容。

---

完整变更对比：v0.9.1...v0.9.2

---

发布通道

通道	本次结果
Open VSX	已发布 ✅
VS Code Marketplace	已发布 ✅
npm · npx @echo-note/gitea-toolkit-mcp	已发布 ✅

v0.9.1

修复

• --help 与 MCP 客户端配置示例里的包名漏了 scope。 原先写的是 gitea-toolkit-mcp，
  而 npm 包名是 @echo-note/gitea-toolkit-mcp —— gitea-toolkit-mcp 只是 bin 名。
  这会把用户引向一个非本项目的同名包，而它恰好出现在用户会直接复制的两处：
  --help 的输出、以及 Claude Desktop / Cursor 的配置片段。已全部修正。

文档

• 重写 packages/mcp-server/README.md —— 它就是 npm 包页面上显示的那一份。
  原先仍把 GitHub Packages 列为安装方式（0.9.0 已移除该通路与包级 .npmrc）、
  版本锁定示例还写着 v0.7.0、而"零配置"被安在了 Release tarball 上。
  现在明确分成两条：① 公共 npm（推荐，无需认证）② Release tarball（备选，访问不了
  registry 时用），并保留「0.7.0–0.8.5 曾用 GitHub Packages、以及为何换掉」的说明。

• 根 README 的「接入 AI 助手」一节：两个方案原先都标着「推荐」、且 tarball 排在 npm 前面 ——
  已调换顺序并去掉重复段落。NPM_TOKEN 一行改为「不要配」（首次发布已完成，正式通道是 OIDC）。

• CHANGELOG 0.3.0 的示例命令同样漏 scope，一并修正。

• 补记一条发布相关的事实：0.9.0 的 npm 包是手动发布的（可信发布要求包已存在，
  首次必须先创建），所以 CI 里那次 npm 步骤显示为跳过、而非发布成功；
  从 0.9.0 起 npx -y @echo-note/gitea-toolkit-mcp 已可直接使用。

为什么这些文档修正值得单独发一个版本：npm 页面上的 README 与终端里的 --help
都只随发布更新 —— 0.9.0 的包页与已下载的 tarball 里仍是上述过时内容。

---

完整变更对比：v0.9.0...v0.9.1

---

发布通道

通道	本次结果
Open VSX	已发布 ✅
VS Code Marketplace	已发布 ✅
npm · npx @echo-note/gitea-toolkit-mcp	未发布 —— 需要关注 ⚠️

v0.9.0

变更

• 独立 MCP 包改发布到公共 npm registry（registry.npmjs.org，此前是 GitHub Packages）。

  0.7.0 时为了让发布流程「不需要额外 secret」，把 @echo-note/gitea-toolkit-mcp 发到了
  GitHub Packages。但那个源有个硬伤：匿名装不了 —— 连公开包也要求先配 PAT 与
  ~/.npmrc；而且 package-lock.json 会硬编码 registry 地址，一旦提交，协作者
  npm install 就会因为没有令牌而失败。用户实际只能去 Releases 下 tarball，体验很差。

  而 ModelScope MCP 广场对「可托管部署」的 STDIO 型服务明确要求包在 npmjs.org / PyPI 上。
  因此改回公共 registry，现在一行即可用：

  npx -y @echo-note/gitea-toolkit-mcp --url https://gitea.example.com --token <令牌>

  顺带：

  • 加上 npm publish --provenance（来源证明，把「这个包确实由本仓库的这次构建产出」
    写进 npm 的签名记录）
  • 移除为 GitHub Packages 写的包级 .npmrc（作用域映射不再需要）
  • Releases 里的 .tgz 附件保留，作为离线 / 固定版本场景的备用通路

  启用方式：仓库 secret NPM_TOKEN（未配置时静默跳过，不阻断发版）。
  唯一前置条件：@echo-note 这个 scope 需已在 npmjs.org 注册。

工程

• npm 发布支持两种认证，且凭据类失败不再阻断发版。

  首次真实发布时踩到 403。原因不是权限范围（令牌对 echo-note 组织有读写权），
  而是账号开启 2FA 后 granular token 必须显式启用「绕过 2FA」，否则 npm 拒绝发布：

  Two-factor authentication or granular access token with bypass 2fa enabled
  is required to publish packages.

  更麻烦的是它把整条流水线卡住了 —— 两个扩展市场其实已经发布成功，
  却因为 release job 需要 publish-npm 成功而一直建不出 GitHub Release。

  现在两处改进：

  • 认证支持「NPM_TOKEN」与「OIDC 可信发布（无需任何令牌）」二选一。
    后者需在 npm 包设置里配置 Trusted Publisher 指向本仓库的 ci.yml；
    本 job 已声明 id-token: write，满足其要求。注意它要求包已存在，
    所以首次发布只能用令牌或本地手动发一次。
  • 凭据类错误（401/403/ENEEDAUTH/EOTP/2FA）降级为「醒目提示 + 跳过」，
    不再阻断 Release —— 凭据是配置问题，不该让已经发出去的市场版本连 Release 都建不出来。
    配置好后重跑即可补齐，发布步骤本身是幂等的。

• CI 的发布 job 由 publish-ghpkg 更名为 publish-npm，权限从 packages: write
  改为 id-token: write（--provenance 与 OIDC 都需要）。

• README 的「接入 AI 助手」一节按公共 registry 重写（原先那段 GitHub Packages 的
  一次性认证说明已不再需要）。

---

完整变更对比：v0.8.5...v0.9.0

v0.8.5

变更

• 作业日志与工作流定义改在「主窗口的只读标签」里打开（此前是输出面板）。

  这个位置换了三次，把结论记在这里。三种做法对比：

  做法	只读	主窗口	查找 / 并排对比	问题
  openTextDocument({content})	✗ 未保存文档	✓	✓	标题是 Untitled-1，关闭时问「是否保存」
  输出面板	✓	✗	✗	不占标签，但检索能力弱、同一时刻只能看一份
  只读虚拟文档（现在）	✓	✓	✓	标题即文件名，.yml 自动按 YAML 高亮

  实现上完全使用平台能力，没有自造查看器：

  • workspace.registerTextDocumentContentProvider() —— 官方类型定义原文就是
    add readonly documents to the editor，只读由 VS Code 保证，扩展不需要自己控制；
    关闭时不会问是否保存，也不会出现「未保存」状态
  • 标签标题与语言由平台从 URI 路径推导：最后一段写什么文件名，标签就显示什么
  • languages.setTextDocumentLanguage() 在需要时明确指定 .yml 按 YAML 高亮
  • onDidChange + EventEmitter<Uri>：重新生成同一份文档时刷新已打开的编辑器

  作业名里不适合当文件名的字符（/、:、*、? 等）会替换成空格并限长 60 字符 ——
  既让标签可读，也避免 / 把 URI 路径「撑开」到别的位置。

• 点击「工作流定义」里的条目改为查看其内容（YAML 原文），不再直接跳浏览器。

  原先左键打开浏览器，而且回落出来的条目全都指向同一个仓库 Actions 页
  （htmlUrl 写死了通用地址）—— 点哪条都一样，等于没有这个功能。
  这是 0.8.4 引入的问题。

  现在左键在主窗口查看工作流定义，「在浏览器打开」保留在右键菜单里，
  与「触发」「启用 / 停用」并列。

• 工作流条目的浏览器地址改用 contents 接口自带的 html_url（精确指向该文件），
  省掉「为了拼网页地址还要再查一次默认分支」的请求。

新增

• 命令 Gitea: 查看工作流定义（gitea.showWorkflow）。
• README 的命令一览补上「工作流」一类（此前漏列了这几个命令）。

工程

• 作业日志不再写入输出面板，原先的 Gitea 工作流日志 输出通道已移除。

---

完整变更对比：v0.8.4...v0.8.5

v0.8.4

修复

• 「工作流定义」一栏永远是空的，而「最近运行」里明明有记录。

  根因在 Gitea 的接口本身：GET /actions/workflows 只枚举 .gitea/workflows，
  完全忽略 .github/workflows。用你实例上的真实数据对照（表格是最直接的证据）：

  仓库	.gitea/workflows	.github/workflows	接口返回
  actions/build-push-action（169 条运行记录）	不存在	10 个 YAML	0 条
  actions/black（有运行记录）	不存在	13 个 YAML	0 条
  GaoXiaogang/cdt_data_assets	不存在	不存在	0 条（正常）

  也就是说，工作流写在 .github/workflows 时（镜像 GitHub Actions 的仓库全是这样），
  这一栏必然是空的 —— 不是扩展的问题，但用户看不到东西。

  现在改成以文件列表为准，接口只用来补「启用状态」：两个目录都列，按文件名与
  接口条目合并。实测同两个仓库能列出 10 / 13 个。

  一开始写的是「接口为空才回落到文件列表」，但那样会漏掉一个仓库同时使用两个目录
  的情况 —— 接口有返回就直接 return 了，.github/workflows 下的看不见。
  这是复查时发现的，已改成两者都取再合并。

  拿不到状态的条目渲染为状态未知：右侧标出所在目录（如 .github/workflows），
  图标不再用「禁止符」—— 不能凭空断言它被停用了。
  另外接口本身失败时也不再让整个分组打不开，降级为「没有状态信息」。

  为什么不干脆用运行记录反推工作流：那样只能看到「跑过的」，
  新加还没跑过的会缺席。列目录才是「定义」的完整来源。

• 点作业只看到「正在获取…」，没有日志内容。

  这一条查下来并不是"面板没打开"，而是服务端确实没有日志可给。接口返回：

  {"message":"not found","errors":["logs have been cleaned up"]}

  Gitea 会对作业日志做保留期清理，旧运行的日志已经不存在了。
  此前这种情况会弹一句指向「令牌」的通用报错（0.8.3 已改为按「没有日志」处理）。

  本次让它明确可辨：

  • 输出面板改用 show() 而不是 show(true) —— 必须确保面板真的被打开并切到该通道，
    让出焦点是次要的
  • 日志为空时额外给一条通知说明原因（运行已取消 / 服务端已清理）

  否则面板里只有一行标题，看起来像「什么都没发生」。实测你实例上那些镜像仓库的旧运行
  基本都属于「日志已被清理」这一类。

---

完整变更对比：v0.8.3...v0.8.4

v0.8.3

修复

• 已取消的作业点开就报「资源不存在，或当前令牌无权访问」。

  作业被取消、或还没开始执行时，服务端根本不存在日志文件，
  GET /actions/jobs/{job_id}/logs 会返回 404 —— 该接口在 Gitea 的 OpenAPI 规范里
  本来就同时声明了 400 与 404。这不是异常，也不是权限问题，但用户看到的是一句
  通用的、指向「令牌」的错误，很容易被误导去查配置。

  现在 404 按「该作业没有日志」处理，并在输出面板里给出真正的原因
  （常见原因：运行被取消、作业尚未开始执行，或日志已被清理）。

  顺带加固了展开「最近运行」时的同类问题：若那条运行记录已被清理，不再抛
  「Gitea 命令失败」的通用弹窗，而是降级成一条说明节点，详细原因写进
  「Gitea: 显示日志」。

变更（界面文案与呈现）

• 作业日志改在输出面板显示，不再弹出未保存的编辑器文档。

  原先用 openTextDocument({ content }) 打开日志，会生成一个未保存的临时文档：
  标题是 Untitled-1、占一个编辑器标签、关闭时还要问「是否保存」，
  而且与「Issue / PR 走详情面板」的体验不一致。

  日志本来就是「输出」类内容，现在统一进 「Gitea 工作流日志」输出面板：
  不占编辑器、不会被误改、随时可用同一条命令切回来；面板顶部写清是哪个仓库的哪个作业。

  每次查看会先清空面板：既避免长时间使用后无限增长，也保证重复点击同一个作业时
  看到的就是它自己的日志。

• 界面里把「Actions」改称「工作流」：仓库节点下的分组、「重跑工作流」命令、
  8 个工作流 AI 工具的显示名与说明、仓库铭牌（Actions 关闭 → 工作流未启用）、
  MCP Server 的自身描述，全部统一。

  内层那个列出 YAML 的分组相应改叫「工作流定义」—— 外层已经叫「工作流」了，
  同名会让树里出现两级一模一样的标签。
  Gitea 自身的功能名（has_actions 字段、gitea_* 工具 ID）保持不变，
  只是面向用户的措辞统一，因此不影响已有配置与集成。

---

完整变更对比：v0.8.2...v0.8.3

v0.8.2

修复

• gitea.pageSize 设成 100 / 500 完全没效果。用户报告「输入 500 或者 100 都无效」。

  根因有两层，缺一不可：

  1. Gitea 服务端对单次请求的条数有硬上限。该值由服务端配置决定，并可通过
     GET /api/v1/settings/api 读到：本实例返回 max_response_items: 50。
     超出部分被静默丢弃、不报错 —— 实测 limit=51/100/200/500 一律只回 50 条。
  2. 本扩展只请求了一页。因此 pageSize 实际语义是「每页条数」而非「展示条数」，
     超过 50 的部分永远拿不到。而默认值恰好是 50，所以改成 100 或 500 后结果完全一样，
     表现为「怎么改都没反应」。

  修复：新增 GiteaClient.requestPaged()，按页收集直到凑够目标条数或没有下一页。
  所有接受 page / limit 的列表操作改走它（仓库 / Issue / PR / 通知 / 提交 / 分支 / Actions），
  因此视图与 AI 工具同时受益 —— 此前 AI 工具声明 limit 上限 100~200，
  实际同样被截断到 50。

  实测（同一实例）：limit 10→10、50→50、51→51、100→100（修复前均为 50）；
  请求 200 时因数据总量只有 105 条而返回 105 条，符合预期；小值（5）行为不变、不会多发请求。

新增

• 列表底部新增「加载更多」，彻底移除条数硬上限。

  上一条修好了「100 拿得到」，但只要还有上限，就会有下一个上限 —— 设 200 之后想要 500 呢？
  所以不该靠不断调大数字，而是改成增量加载：

  • 列表底部若还有更多，出现一个「已显示 N 条，点击加载更多…」的条目
  • 点击后按 gitea.pageSize 追加下一批，没有上限
  • 首次展示的条数仍由 gitea.pageSize 决定（即它的语义是「初始条数」）

  已接入全部列表：仓库、分支、打开的 Issue / PR、Actions 运行记录，
  以及「我的 Issue / 我的 Pull Request / 通知」三个视图的各分组。

  实现上给 BaseTreeProvider 加了 capOf / raiseCap 记录每个列表已加载的条数，
  并由 gitea.loadMore 命令提升上限后刷新。节点的 listKey 带仓库坐标，
  因此不同仓库的同名分组互不干扰。

变更

• gitea.pageSize 的说明改为「列表类视图初始展示多少条」，并在 schema 里补上
  minimum: 1 / maximum: 200。之前 schema 没有任何范围约束、描述只写「分页大小」，
  用户无从知道有效的取值范围与服务端限制；现在也无需靠调大它来「看全」了。

新增（仓库视图）

• 按组织分组：仓库按 owner 归入 组织名（数量） 分组，其余按仓库数降序。

• 聚焦当前仓库：含当前工作区仓库的那一组置顶 + 默认展开，该仓库在组内排第一
  并标注 ★ 当前。选这个做法而不是「额外放一个置顶条目」是为了避免同一仓库在树里出现两次。

• 仓库铭牌（右侧灰色文本）：语言、分支数、开放 Issue / PR 数、Actions 关闭、已归档。
  计数为 0 的不显示 —— 实测本实例绝大多数仓库的开放 Issue / PR 都是 0，全显示只是噪音。

  只使用列表接口已返回的字段，不产生任何额外请求。因此 Actions 关闭 表达的是
  功能开关，不是「仓库里没有 workflow 文件」—— 后者需要逐个仓库调
  /actions/workflows，上百个仓库就是上百次请求，不能放在列表渲染路径上。

• 搜索仓库（视图标题栏）：走服务端 /repos/search，因此覆盖全部仓库，
  不受 pageSize / 「加载更多」限制。搜索时结果平铺不分组（结果是跨组织的，
  分组反而妨碍扫读），列表首行显示过滤条件且可点击清除，标题栏的清除按钮仅在有过滤时出现
  （用 setContext 驱动 when）。

  实测记录一处容易踩的：服务端不按纯 owner 名搜索 —— 搜 devops 得 0 个，
  但搜 devops/cdt-ams 或 cdt-ams 各得 1 个。提示文案与空结果说明都按此写明了。

• 新增 src/vscode/views/repoBadge.ts：刻意不依赖 vscode 模块（与 icons.ts 同一约定），
  这样铭牌逻辑能用真实数据离线渲染预览，而不是只能在扩展宿主里跑。

工程

• 三个发布通道改为并行 job，不再是同一个 job 里连续的三步。
  原来串行本身不是大问题，真正的毛病是任一步失败会让后面的步骤被整体跳过 ——
  例如 Open VSX 出错，会导致 Marketplace 压根不去尝试发布。

  现在拆成四个 job：resolve（解析版本 + 判断该版本是否已发）、三个 publish-*
  （Open VSX / VS Code Marketplace / GitHub Packages，并行执行、独立成败）、
  以及 release（建 tag 与 Release）。「市场发布必须先于创建 Release」这条不变，
  由 needs 保证 —— 否则重跑时该版本会被判定为「已发」而永远上不了架。

• Release 说明改从 CHANGELOG 提取（新增 scripts/release-notes.mjs）。
  原先是 gh release create --generate-notes，那生成的是按 commit / PR 自动罗列的
  摘要，与 CHANGELOG 里那份有分类、有原因、有实测数据的说明完全是两回事 ——
  结果是 Release 页面看不到真正的变更说明。

  现在三者同源：扩展市场的 Changelog 标签页 / .vsix 里的 CHANGELOG / Release 说明。
  自动摘要原本附带的版本对比链接由脚本补回。

• 新增 npm run check:changelog，防止未填写的 CHANGELOG 区块再次发给用户。
  scripts/bump-version.mjs 升版本时会在 CHANGELOG 顶部插入一个「待补充」区块，
  而它不会自己消失 —— 0.8.1 就是这么把占位文本发到了市场（该条目本次已补上）。
  CHANGELOG 会进 .vsix、也会显示在扩展市场的 Changelog 标签页里，
  所以这不是内部问题，而是用户看得见的内容。

  校验两件事：一是没有未填占位（待补充 / 待填写 / TODO: …），
  二是最新版本标题与 package.json 的 version 一致。
  已接入 npm run ci，并且是 CI verify job 的一步 —— 依赖链是
  release → publish-* → package → verify，因此能真正挡住发布，而不只是发个警告。

---

完整变更对比：v0.8.1...v0.8.2

v0.8.1

Full Changelog: v0.8.0...v0.8.1