backend-only 项目无法忽略 ui_quality / UIUX 验收，quality 仍被前端门禁卡住

[idoall]

问题描述

在一个明确的 backend-only / API-first 项目中，即使文档、workflow state 和配置都已经声明本轮 不需要 standalone frontend、不验收 UI/UX、不要求 design token / frontend runtime，super-dev quality 仍然持续把项目卡在前端相关门禁上，导致 release closure 无法按 backend-only 口径收口。

预期行为

对于 backend-only / CLI+HTTP review surface 项目：

• 可以显式声明 ui_quality 不参与验收
• PRD/Architecture/UIUX 决策与证据闭环 可以按 PRD + Architecture + backend evidence 解读，而不是强制要求 UIUX 参与 release gate
• UI 契约、Design Token 与运行时验证闭环 不应成为 backend-only 项目的 blocker
• 如果配置中声明 frontend: none、ui_library: none、style_solution: none，则 quality/readiness/proof-pack 应自动降级或跳过前端相关 gate

实际行为

即使已经：

• 在 workflow / docs 中明确声明 backend-only
• 在 closure note / validation docs 中明确声明忽略 ui_quality
• 在 delivery manifest 中声明：
  • backend_first: true
  • standalone_frontend: false
  • primary surfaces 为 CLI、HTTP API、signal snapshot persistence、go test verification

重新执行 super-dev quality 后仍然得到：

• 总分 70/100
• 仍失败于：
  1. PRD/Architecture/UIUX 决策与证据闭环
  2. UI 契约、Design Token 与运行时验证闭环

同时 CLI 还报出配置字段不被识别：

• delivery_profile
• delivery_surfaces
• design_token_required
• frontend_governance_mode
• frontend_runtime_required
• governance_notes
• preview_runtime_required
• ui_review_required
• ui_ux_required

这表明当前 CLI 没有消费 backend-only exemption / override 配置，导致 backend-only 项目仍然被前端 rubric 强行卡住。

复现上下文

项目特征：

• backend: Go
• platform: API
• frontend: none
• ui_library: none
• style_solution: none
• testing_frameworks: go-test

本地配置示意：

platform: api
frontend: none
backend: go
ui_library: none
style_solution: none
testing_frameworks:
  - go-test

然后即使把文档口径全部收束为 backend-only，再执行：

super-dev quality

仍然会失败在 UI / UIUX / Design Token / runtime 相关项。

影响

这会让 backend-only 项目无法按真实交付范围收口：

• 代码和后端交付面已经完成
• go test ./... 通过
• CLI / HTTP / snapshot evidence 已齐
• 但 quality / proof-pack / readiness 仍然被前端类检查阻塞

结果只能靠人工在文档里解释 “tool-limited / rubric mismatch”，无法通过工具本身正确表达 backend-only release closure。

建议修复方向

建议支持至少一种方式：

1. 正式配置开关

   • 例如允许声明 backend-only / no-ui iteration
   • 让 quality / proof-pack / readiness 自动跳过 UI-only gate

2. 基于现有配置自动推断

   • 如果 frontend: none + ui_library: none + style_solution: none
   • 则默认不启用 ui_quality / design-token / frontend-runtime gating

3. 更细粒度的 gate exemption

   • 允许显式关闭：
     • ui_quality
     • uiux_as_acceptance_gate
     • frontend_runtime
     • design_token_closure

附加说明

如果这是当前设计使然，也希望文档里明确说明：

• backend-only 项目当前是否官方支持
• 如果支持，正确配置方式是什么
• 如果不支持，是否计划支持

谢谢。

[shangyankeji]

感谢反馈
当前 2.4.0 在 backend-only / API-first 项目上的交付门还没有完全按 backend-only 口径收口。现状是 quality、proof-pack、release readiness 这几条链里，UIUX / design token / frontend runtime 相关闭环仍然会默认参与验收，所以即使项目已经明确声明：
frontend: none
ui_library: none
style_solution: none
也可能继续被前端类 gate 卡住。
这不符合 backend-only 项目的真实交付范围。
这条我会按下面顺序补：

1. 正式支持 backend-only / no-standalone-frontend delivery profile
2. 让 frontend: none + ui_library: none + style_solution: none 可以自动推断为 backend-only
3. 在 quality / proof-pack / readiness 中按 profile 自动降级或跳过：
   ui_quality
uiux_as_acceptance_gate
design_token_closure
frontend_runtime
4. 如果当前项目仍保留少量 review surface，也只验该 surface 对应证据，不再强行按 standalone frontend 口径验收
   在这条修复正式落地前，backend-only 项目的 release 结论应优先以：
   原生测试结果
   backend evidence
   API / CLI / runtime evidence
   为准，不应把当前前端类 gate 直接当成项目本身未完成。