Skip to content

v1.9.0 — Evidence Packet 与可信交接闭环

Latest
Latest

Choose a tag to compare

View all tags
@SakuraCianna SakuraCianna released this 28 Jul 04:17
v1.9.0
3e1cdbb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

v1.9.0 发布说明

发布日期：2026-07-28。发布目标为 v1.9.0；不可变 Git commit、npm 完整性值和工作流结果以 GitHub Release 与 npm registry 记录为准。

版本重点

v1.9.0 建立统一证据模型和可信交接边界，让 Issue、Pull Request 与 release ref 的关键结论不再只依赖自由文本。版本同时收紧仓库文本的提示词注入防护，并把正式 Node.js 运行范围从 24-only 扩展到 Node 22 与 24。

新增功能

  • 新增只读工具 sdlc_evidence_packet，支持 issue、pull_request 和 release 三种 subject。
  • 每个 evidence item 包含稳定 ID、item-level subject、state、freshness、completeness、source、采集时间、provenance、limitations 和 recommended next actions。
  • packet 带 schemaVersion、generatorVersion 和 SHA-256 contentDigest。digest 纳入 subject、状态、freshness、completeness、provenance 和 limitations，排除采集时间等易变 envelope 字段。
  • PR packet 固定 head SHA；采集期间 head 变化时，整包标记为 stale 并要求重新采集。
  • Release packet 独立采集 ref→SHA、release readiness 和 security triage；单个来源失败返回 partial evidence，不会把未知状态误报为 clean。
  • Release ref 会先尝试解析为 immutable SHA；成功后 readiness 固定到该 SHA，失败时仍以原始 ref 做降级采集，但 target/readiness 保持 unverified/partial。Repository-wide security evidence 使用独立 repository subject，不错误继承 release SHA。
  • packet 强制 GitHub request、源文本、文件/单源项目、Markdown、evidence item 与 timeout 上限，并返回 budget 与 omittedEvidence；单个聚合源超过 30 秒会触发 AbortSignal 并降为 partial。
  • agent_handoff_packet 不再强制调用方自报 currentStatus，默认从系统证据派生状态，并支持 release ref、goal、non-goals、completed actions、decisions 和 next steps；仓库、Issue、PR、policy 与深度 evidence 共用 30 秒可中止总采集预算。
  • MCP 工具目录集中为公共 catalog，并由真实 MCP 协议测试验证 13 个工具与静态 handoff resource 一致。
  • create_pr_summary 现在直接返回统一 EvidenceItem，证据绑定 PR head SHA；changed-file 采集被截断时显式标记为 partial。

安全改进

  • 新增公共 prompt-injection 检测层，覆盖：
    • 指令覆盖与 system/developer 角色伪装；
    • 绕过确认的工具调用胁迫；
    • token、API key、cookie、私钥、密码和环境变量外传；
    • 仓库/源码向外部 URL 外传；
    • Base64、ROT13 等编码后执行指令；
    • 零宽字符和双向控制符混淆。
  • 任何被检测到的注入信号都不会进入 agent-facing Markdown 或 handoff prompt；原始值保留在 structuredContent 中，供调用方按“不可信数据”审查。所有成功工具响应同时提供 _meta 与 structuredContent.trustBoundary，避免 structured-only 客户端丢失信任边界。
  • Issue/PR 源文本超过 20,000 字符，或 PR changed-file 列表不完整时，prompt-injection evidence 固定降为 unverified/partial；未扫描的后缀与文件名不能被解释为“没有风险”。
  • repo_context 对仓库描述、topics、package scripts、workflow 文件名、agent instructions、README、策略、Issue 与 PR 元数据逐字段防护并报告来源。
  • agent_handoff_packet 对 current status、goal、non-goals、completed actions、decisions、next steps 和 Issue/PR/release 元数据报告 prompt-injection warnings。
  • branch_protection_status 区分“已验证没有保护”和“权限不足无法验证”；后者返回 unknown，不再误报 unprotected。
  • security_triage 的注册边界会安全处理本地初始化异常，不回显内部错误详情；每类最多采集 200 条并探测额外一页，超过预算会标记 truncated，Markdown 只展示最高优先级前 50 条并报告省略数量。
  • 本地 JSON 配置文件在支持 POSIX mode 的平台上以 0600 创建，并在读取已有配置前收紧权限；Windows 仍依赖用户目录 ACL。
  • npm 与 MCP Registry OIDC 发布只接受 GitHub Release 事件，并在发布前验证 tag 与 package 版本一致、目标提交属于 main、lockfile/server/registry metadata 一致；所有可获取 OIDC 权限的第三方 Action 固定到完整 commit SHA。
  • 复核 GHSA-frvp-7c67-39w9：上游维护者将当前锁定的 @hono/node-server@1.19.15 列为 1.x 修复版本；项目经 MCP SDK 仅使用根入口的 getRequestListener，不导入 @hono/node-server/serve-static，也不提供 URL 到本地文件系统的静态文件路由。

行为与兼容性变化

  • 包版本、运行时版本与 MCP Registry metadata 同步到 1.9.0。
  • engines.node 从 >=24 调整为 >=22。
  • CI 在 GitHub Actions 上同时运行 Node 22 与 Node 24。维护者本机不要求同时安装两个版本。
  • Node 20 不属于正式支持范围。它已结束维护；即使当前源码可能运行，项目也不为其提供 CI、依赖兼容或安全修复承诺。
  • 新增工具和现有 schema 变化保持 additive；默认 stdio 启动方式不变。
  • 静态 SDLC 标准改为遵循仓库自身 review/traceability policy，不再假设每个仓库都必须有额外人工 reviewer 或每个 commit 都必须关联 Issue。

本地运行与远程边界

  • stdio 仍是默认与推荐传输。
  • Streamable HTTP 仍只绑定 loopback，面向可信本机客户端。
  • 不要把本地 HTTP 端点暴露到局域网、互联网或反向代理后。
  • Remote OAuth 和多租户托管不在当前路线图。若未来重新立项，必须先满足远程部署重新立项准入条件。

升级步骤

  1. 安装 Node.js 22 或 24。
  2. 更新 MCP 客户端使用的 npm 版本或重新运行 npx -y agentic-sdlc-mcp。
  3. 保持 GITHUB_TOKEN、GITHUB_OWNER、GITHUB_REPO 与 SDLC_DEFAULT_BRANCH 的现有配置。
  4. 先调用 repo_context 验证连接。
  5. 对需要归档的 Issue、PR 或 release ref 调用 sdlc_evidence_packet。
  6. 如果消费 structuredContent，按 schemaVersion 解析，并容忍 additive 字段。

验证与发布门禁

发布前必须完成：

  • npm ci
  • npm run check:line-endings
  • npm run typecheck
  • npm run build
  • npm run test
  • npm run smoke
  • npm run test:coverage
  • GitHub Actions Node 22 与 Node 24 matrix 全部通过
  • 独立 reviewer 审查需求完成度、安全、类型、性能、回归、风格、测试与文档

已知限制

  • Prompt-injection 检测是可解释的启发式模式防线，不是自然语言安全证明；安全讨论、引用的攻击样例等正常文本可能被保守拦截，未命中的语义改写、同形字或分词攻击仍必须视为不可信数据。需要诊断时只在 structuredContent 中按不可信数据检查原文。
  • contentDigest 用于发现同一 schema/generator 下的稳定内容变化，不是数字签名，也不构成法律或合规审计证明。
  • Security alert、branch protection、ruleset 和 CI evidence 受 GitHub 功能与 token 权限影响；权限不足会产生 partial/unverified/unknown。
  • Node 22 只在 GitHub Actions 验证，因为维护者本机未安装 Node 22；发布前不得把本机 Node 24 结果等同于 Node 22 结果。
  • npm audit 当前把公告范围统一为 <2.0.5，因此仍会对 Hono 与 MCP SDK 报告两个 moderate；本版本依据上游维护者列出的 1.x 修复版本和静态不可达性接受这两个告警，不把它们描述为审计全绿。若未来降级到 @hono/node-server<1.19.15、引入 @hono/node-server/serve-static，或新增任何 URL 到文件系统的静态资源映射，必须重新进行路径穿越评估。

回滚

如果 v1.9.0 出现兼容性问题：

  1. 在 MCP 客户端固定上一稳定版本，例如 npx -y agentic-sdlc-mcp@1.8.0。
  2. 若 latest dist-tag 需要回退，维护者执行 npm dist-tag add agentic-sdlc-mcp@1.8.0 latest，并对问题版本执行 npm deprecate agentic-sdlc-mcp@1.9.0 "<原因与替代版本>"。
  3. npm 已发布版本不可覆盖或复用；修复必须使用新版本（例如 1.9.1），不得重新发布同一个 1.9.0。
  4. 将 GitHub Release 标记为问题版本，修正 MCP Registry 指向，并保留失败 workflow 与 npm 完整性记录。
  5. 不修改现有 GitHub token 或仓库权限。
  6. 保存失败的 tool name、输入 schema 版本、Node 版本和脱敏错误。
  7. 创建 Issue，并说明是 Markdown、structuredContent、Node 运行时还是 GitHub 权限回归。

下一版本未完成项

  • v1.10：MCP Inspector 契约、稳定 agent evaluation、性能预算与故障注入。
  • v1.11：SBOM/provenance、供应链 gate、coverage 治理和隐私安全可观测性。
  • GitHub Code Scanning 与 Dependabot alerts 的仓库级库存受功能开关或 token 权限限制，本次只能标记为 partial，不能宣称远端告警为零。
  • 远程 OAuth/多租户仍是条件触发项；只有出现真实远程使用场景并满足独立威胁模型、请求级身份隔离与多租户测试门槛后才重新立项。
Assets 2
Loading