Reported issues for Agentic SDLC MCP

Pod holds 14 of 14 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Agentic SDLC MCP.

Most discussed

[v1.10] 建立 Agent Evaluation、响应预算与故障注入基线

背景

handler 单测和协议可调用不等于 coding agent 会正确发现、选择并组合工具。v1.10 需要稳定、可重复、带 provenance 的 evaluation，并把产品硬预算、观测指标和 GitHub 故障注入分开，避免把 recorded trace 或低置信度启发式误报成真实模型能力或已确认漏洞。

前置条件

依赖 #43 的真实 MCP 双 era 契约矩阵。evaluation 不得绕开注册层直接调用 handler，也不得访问持续变化的公开仓库作为唯一真值。

范围（T7–T11）

• T7：定义版本化 scenario/trace/result schema、确定性 scorer 和 provenance
• T8：建立 6 个基础工具发现/选择场景
• T9：建立 6 个多工具、安全关键与提示词注入场景
• T10：测量 items、API calls、字符、JSON bytes、timeout 等确定性硬预算；token 仅作为标明算法的 estimate，P95 仅在固定 mock runner 报告
• T11：注入 4

Read the thread · 2026-07-13 · closed · 3 comments

[v1.10] 建立 MCP Inspector 与全工具契约兼容测试

背景

v1.9.0 已有真实 MCP SDK Client + InMemoryTransport 的 initialize、工具/资源发现与 resource read 基线，也已有 loopback Streamable HTTP 的 Host/Origin、请求隔离、body limit、错误与关闭语义测试。当前缺口不是“完全没有真实 client”，而是尚未形成不可变发布契约、全部 13 个工具矩阵、进程外 Inspector 黑盒，以及 SDK v2 下 2025/2026 双 era 的明确兼容证据。

范围（T1–T6）

• T1：从不可变 v1.9.0 tag/commit 生成 tools/resources 契约 manifest 与 breaking/additive 比较器
• T2：迁移官方 TypeScript SDK v2 分包，先保持 2025 legacy wire parity
• T3：仅为本地 stdio 与 127.0.0.1 loopback HTTP 显式提供 2025/2026 双 era
• T4：通过真

Read the thread · 2026-07-13 · closed · 1 comment

[v1.11] 增加隐私优先的可观测性与安全降级

背景

degraded、timeout、rate limit、stale evidence、截断和策略解析失败目前缺少统一可观测信号；同时 telemetry 如果缺少数据边界，可能泄露 Issue/PR 正文、仓库内容或凭据。

范围

• 定义低基数 metrics：调用量、延迟、GitHub API 次数、rate-limit、degraded/unverified、stale、截断和错误类别
• 使用 correlation ID 串联单次 MCP request 的子调用
• 建立日志/metrics/trace 数据字典、redaction、retention、高基数限制和 opt-in 策略
• telemetry 默认关闭或最小化；远程发送必须显式 opt-in
• 为 timeout、rate-limit、provenance failure、evidence stale 和 policy parse failure 定义可行动告警
• metrics backend 不可用时保持工具主路径可用，并采用有界 buffer/丢弃策略

验收标准

Read the thread · 2026-07-13 · open · 0 comments

[v1.11] 建立分层 Coverage 门槛与长期测试资产治理

背景

项目已有首轮全局 coverage regression floor 和 805 个测试，但 config、resources、prepare、handoff、PR summary 等模块仍应采用分层门槛。覆盖率提升不能依赖排除文件、脆弱快照或只测实现细节。

范围

• 在现有全局 floor 基础上建立核心/高风险/低覆盖模块的分层 threshold
• 优先提升 config、resources、prepare、handoff、PR summary 与 HTTP 边界覆盖
• 建立 fixture/recording/golden answer 的版本、来源、失效和审查规则
• 增加权限、分页、竞态、取消、超限、恶意输入和跨模块业务关联测试
• 记录慢测试、flake、重复 fixture 和维护成本，支持可控重构

验收标准

• 分层 coverage threshold 进入 CI，低于门槛明确失败
• 不通过排除低覆盖文件、删除测试目标或只测生成代码提高百分比
• 核心/高风险路径覆盖 happy path、失败、边界、

Read the thread · 2026-07-13 · open · 0 comments

[v1.11] 加固 GitHub Actions 与发布供应链证明

背景

当前 npm/Registry 已使用 OIDC，但多数第三方 Actions 仍使用可变 major tag，发布物缺少统一 SBOM、artifact attestation 和 tag/package/Registry/commit 一致性证明。

范围

• 所有第三方 Actions 固定完整 commit SHA，并通过 Dependabot 或受控流程更新
• 增加 dependency review、适用的 CodeQL、OpenSSF Scorecard 与许可证/恶意包风险检查
• 保持 npm/Registry OIDC 最小权限，并分别验证 provenance 与目标版本
• 生成 SBOM 和 artifact attestation/SLSA provenance
• 验证 tag、package version、Registry version、artifact digest、SBOM 和 attestation 指向同一 commit
• 对 lockfile、install scripts、新依赖、Actions、容器/二进制下载

Read the thread · 2026-07-13 · open · 0 comments

[条件触发] 实施 HTTP 预算、取消语义与非明文凭据迁移

背景

框架默认 body limit 不能替代产品级安全预算；当前 GitHub client 也缺少统一 timeout、retry/backoff、rate-limit metadata 和 cancellation。交互式配置仍可能把 token 明文写入普通 JSON。

前置条件

与“RequestContext、远程 HTTP 认证与租户隔离”Issue 共用 request-scoped context，不建立旁路实现。

范围

• 定义 JSON body、header、工具参数、响应、连接、并发、rate limit、timeout 和 cancellation 预算
• 支持慢客户端、断开连接清理、graceful shutdown 与进行中请求的确定语义
• 为 Octokit 统一 timeout、有限重试/backoff、rate-limit metadata 与 AbortSignal
• 默认不再把 token 写入普通 JSON，只保存非敏感 owner/repo/default branch
• 支持环境/MCP secret

Read the thread · 2026-07-13 · open · 0 comments

[条件触发] 建立 RequestContext、远程 HTTP 认证与租户隔离

背景

v1.8 已完成 local HTTP 的 loopback、Host/Origin、请求级无状态 transport 和安全错误基线，但远程 HTTP 仍缺少 OAuth、调用方身份、请求上下文和多租户隔离。进程级 config 与单例 Octokit 不能安全承载 remote profile。

范围

• 明确 stdio、local HTTP、remote HTTP 三种运行 profile，默认仍为 stdio
• remote HTTP 遵循 MCP Authorization/OAuth 约定，校验 issuer、audience、expiry 与 scope
• 引入不可变 RequestContext / ToolExecutionContext / ToolDependencies
• remote profile 使用 per-request GitHubClientFactory 与 credential handle
• repo、client、policy/evidence cache、correlation ID 与

Read the thread · 2026-07-13 · open · 0 comments

[v1.9] 统一现有工具 Evidence 契约并防止 resources 漂移

背景

即使新增统一 evidence packet，现有 PR summary、gate、review、security、release 与静态 resources 如果继续维护各自的状态字段和模板，仍会产生 schema/Markdown/文档漂移。

前置条件

依赖 #31 的统一 Evidence Model；与 #32 的 handoff 改造并行协作。

范围

• 让 PR summary、quality gate、review、security triage、release readiness 使用统一 evidence item 或明确适配层
• 为 handoff/release resources、工具 schema、structuredContent 与 Markdown 建立 snapshot/contract tests
• 建立统一的预算、partial/stale/omitted 聚合规则和安全渲染器
• 记录每个子调用成功、失败、截断、权限不足和 provenance 缺口

验收标准

• 各 evidence 生产

Read the thread · 2026-07-13 · closed · 0 comments

Most recent

[v1.9] 将 agent_handoff_packet 升级为可信可续接上下文包

背景

当前 agent_handoff_packet 的 current status、decisions 和 next steps 主要由调用方自由文本提供，系统只补充 Issue/PR 基本信息。下一位 agent 无法可靠区分系统验证事实、调用方断言、过期证据和未知信息，容易重复探索或继承错误假设。

前置条件

• 依赖 #31 的统一 Evidence Model 与 provenance 语义。
• 必须保持现有 handoff 调用方式兼容，新增字段优先采用 additive 演进。

范围

将 agent_handoff_packet 升级为可信 continuation packet，至少包含：

• 当前目标、非目标与工作边界
• 已完成、未完成和未验证动作
• 相关 Issue、PR、commit、branch、subject SHA 与当前 checks
• 最近失败检查、风险、阻塞项和剩余验证
• decisions、rationale 与 repository policy/release readiness 摘要
• 下一步推

Read the thread · 2026-07-09 · closed · 0 comments

[v1.9] 建立统一 Evidence Model 与 sdlc_evidence_packet

背景

v1.9 需要把分散在 PR summary、quality gate、review、security triage、release readiness 与 handoff 中的判断统一成可审查的证据模型。当前输出缺少统一 ID、subject SHA、freshness、completeness、provenance 和版本语义，调用方自报状态也可能与系统验证事实混在一起。

前置条件

• v1.8.0 的风险感知 prepare_work_item 与上下文证据采集已经发布。
• 本 Issue 是 #32 以及 v1.9 其他 evidence 消费方的基础契约。

范围

1. 定义统一 Evidence Model，每个 evidence item 至少包含：
   • id、kind、subject（repo/Issue/PR/ref/SHA）
   • state: verified / failed / pending / unverified / not_applicable
   • `freshn

Read the thread · 2026-07-09 · closed · 0 comments

[v1.7] 让仓库策略驱动门禁、审查、发布与交接

背景

仓库策略必须持续影响 PR 审查、合并门禁、发布判断和 agent 交接，不能只停留在 repo_context 或规划阶段。

前置条件

依赖策略加载能力，以及 v1.6 的 quality gate/review 增强。

范围

让以下工具消费仓库策略：

• quality_gate_status
• review_pr_against_standard
• release_readiness_check
• agent_handoff_packet

策略字段包括 requiredChecks、protectedPaths、releaseBlocking labels、requireIssueLink、requireCodeOwnersForProtectedPaths、requireChangelog、requireRollbackPlan。

验收标准

• requiredChecks 缺失时 gate 产生 blocker 或 pending evidence
• protectedPaths 命中时

Read the thread · 2026-07-09 · closed · 0 comments

[v1.7] 让仓库策略驱动计划与 Issue 草稿

背景

策略被读取后，需要首先影响规划阶段，使 agent 在创建工作项前就看到仓库约束，而不是在 PR 阶段才发现不符合要求。

前置条件

依赖 .agentic-sdlc.yml 策略加载与校验能力。

范围

让 plan_from_context 和 create_issue_set 消费仓库策略：

• defaultWorkType 影响未显式指定的任务分类
• requiredChecks 进入计划、Issue 验收标准和验证建议
• protectedPaths 触发 security/ownership gate
• 策略标签只在仓库真实存在时进入 issueDrafts
• 输出 policySources，说明规则来源

验收标准

• defaultWorkType 可改变未显式指定 workType 时的默认值
• 调用方显式 workType 优先于策略默认值
• requiredChecks 自动进入计划、issueDrafts 和验证建议
• `protect

Read the thread · 2026-07-09 · closed · 0 comments

[v1.7] 实现 .agentic-sdlc.yml 策略加载与校验

背景

不同仓库对 checks、protected paths、review 和 release 的要求不同，需要仓库级策略入口，而不是完全依赖 MCP 内置默认值。

建议配置

defaultWorkType: feature
requiredChecks:
  - test
  - typecheck
protectedPaths:
  - ".github/**"
  - "src/config.ts"
labels:
  releaseBlocking:
    - release-blocker
    - security
review:
  requireIssueLink: true
  requireCodeOwnersForProtectedPaths: true
release:
  requireChangelog: true
  requireRollbackPlan: true

范围

• 定义 .agentic-sdlc.yml 的 Zod schema 和 TypeScript 类型
• 实现 GitHu

Read the thread · 2026-07-09 · closed · 0 comments

[v1.6] 强化 review_pr_against_standard 结构化审查

背景

现有 review_pr_against_standard 偏向通用 diff 检查，需要根据任务类型、变更范围、验证证据和仓库治理信号，给出更接近真实 reviewer 的结构化判断。

审查维度

• intent：PR 描述是否说明目的和背景
• scope：文件变更是否与目标一致，是否存在范围膨胀
• evidence：测试、构建、文档、复现和回归证据是否匹配变更
• ownership：CODEOWNERS 是否覆盖关键路径，相关 owner 是否参与审查
• policy：是否违反仓库治理要求
• fallback：是否包含回滚或降级说明
• security：是否触碰 token、env、auth、workflow 权限、依赖锁文件或发布配置

任务类型差异

• docs-only：不要求代码单元测试，但要求示例、链接或 Markdown 验证
• feature：要求测试，或明确说明为什么无需测试
• bugfix：要求复现说明和回归测试
• security：要求威胁、权限、密钥和安全验证说明
• workfl

Read the thread · 2026-07-09 · closed · 0 comments

The remaining reports are on the project's issue tracker.