评审真实性增强：前端硬规则+人工启动方案+文档-实现三级校验

- 前端存在性硬规则：detectFrontend 源码级判定，web形态无真实前端/不可访问 → 实现完整度封顶50%（CLI/插件豁免）
- verify 多态：build_status 支持 done/failed/done_no_ui，前端按钮新增「无前端」
- 人工启动方案：评审环境自动启动失败 → awaiting_browse 暂停，评委手动启动后填 service_url 走 /verify-browse 恢复（SSRF 信任评委确认地址）
- Gitea 稳定性：clone 自动重试×3（525抖动）+ 每队独立 token 回退（全局账号失效兜底）
- A 阶段报告备份：feature_inventory.__stageA_report 防 B 阶段维度重复累积/A维度丢失
- tryTest 依赖预装：Python 项目自动 pip install（测试不再因缺依赖误判失败）
- 运行验证压缩静态维度：前端缺失+测试失败 → 静态纸面维度封顶50%（防原型拿高分）
- 文档-实现三级校验：claim-consistency 注入运行时证据（构建/测试/前端），识别「代码有但跑不起来」的虚报（逸飞冲天 61%→25%）
- 赛事文档：中期20%+最终80%（AI=人工总分）、评审表/评审规则/赛事说明/07设计同步
- 清空 review_snapshots 测试污染数据，保留当前正式分（零号158/逸飞冲天126）
- 测试 446 全通过（后端435+前端11）

server/config/standards/技术大赛-赛道一.md

@@ -1,93 +1,101 @@
-### 1. 场景价值与技术合理性（10分）
+### 1. 场景价值与技术合理性（15分）
+
+**前置门槛（真实性锚点，2026-08-27）：本维度得分不得超过「实现完整度与稳定性」维度得分。** 系统跑不起来/实现不完整时，场景再动人也无效——场景价值必须建立在真实可运行的系统之上。
 
 检查以下4项：
 
-1. 真实需求（3分）
+1. 真实需求（4分）
    - 解决的是真实业务需求还是虚构场景
    - 有明确的行业/用户场景
 
-2. Agent不可替代性（3分）
+2. Agent不可替代性（4分）
    - 为什么非用Agent不可，不是传统脚本/工具能解决的
    - Agent的自主决策/工具调用/多步推理是否必要
 
-3. ROI可量化（2分）
-   - 效率提升/成本降低等有数据支撑
+3. ROI可量化（4分）
+   - 效率提升/成本降低等有数据支撑（优先引用「效果与数据」维度的真实测试/基准数据）
    - 效果的量化指标明确
 
-4. 场景文档完整性（2分）
+4. 场景文档完整性（3分）
    - 业务背景、痛点分析、方案对比齐全
    - 需求文档结构完整
 
 > 无场景文档 → 0分
+> 系统构建失败 → 本维度最高只得 5 分（真实性问题：场景价值未落地为可运行系统）
 
 ---
 
-### 2. 开发范式应用（5分）
+### 2. 开发范式应用（8分）
 
 检查以下3项：
 
-1. 开发流程覆盖（2分）
+1. 开发流程覆盖（3分）
    - AI日志是否覆盖需求分析→设计→编码→测试的完整流程
    - 流程各阶段有明确记录
 
-2. 设计文档质量（2分）
+2. 设计文档质量（3分）
    - 是否有需求分析、架构设计、接口设计文档
    - 文档之间逻辑一致
 
-3. 测试文档质量（1分）
+3. 测试文档质量（2分）
    - 是否有测试用例、测试计划、测试报告
    - 测试结果可复现
 
 > 没有任何一个维度的证据 → 0分
+> 系统构建失败 → 本维度最高只得 3 分（开发范式须以真实可运行系统为落点）
 
 ---
 
-### 3. 架构设计（10分）
+### 3. 架构设计（15分）
 
 架构文档存在性 + 代码反向推断。
 
-1. 架构文档存在且质量高（3分）
+**前置门槛（真实性锚点，2026-08-27）：本维度得分不得超过「实现完整度与稳定性」维度得分。** 架构设计必须与实际可运行代码一致——代码无法构建/运行，则架构只是纸面设计。
+
+1. 架构文档存在且质量高（4分）
    - 有 DESIGN.md / docs/design.md 等完整文档
    - 包含系统模块划分、组件关系、数据流
 
-2. 模块化与分层（3分）
+2. 模块化与分层（4分）
    - 代码是否按职责分层、模块间依赖是否合理
    - 高内聚低耦合
 
-3. 数据流清晰度（2分）
+3. 数据流清晰度（4分）
    - 数据流转路径是否可追溯
    - 状态管理一致
 
-4. 可扩展性（2分）
+4. 可扩展性（3分）
    - 是否有接口抽象、插件机制等便于扩展的设计
    - 预留扩展点
 
 **文档规则：**
-- 有完整架构文档：可评至满分10分
-- 无文档但有代码证据：封顶5分（允许根据代码结构反向推断模块/分层/数据流）
-- 无文档且代码混乱：1-3分
+- 有完整架构文档且系统可构建运行：可评至满分15分
+- 无文档但有代码证据（系统可构建）：封顶8分（允许根据代码结构反向推断模块/分层/数据流）
+- 无文档且代码混乱：1-4分
+- 系统构建失败：本维度最高只得 5 分（架构真实性存疑）
 
 ---
 
-### 4. 工具使用与Skill集成深度（5分）
+### 4. 工具使用与Skill集成深度（10分）
 
 AI框架集成深度 + 开发工具链。
 
-**AI框架集成（3分）：**
+**AI框架集成（6分）：**
 - 无框架使用 → 0分
-- 使用框架基本功能（chain/pipeline）→ 1分
-- 实现了MCP/Function Calling协议 → 2分
-- 自定义Agent工具链、有深度框架定制 → 3分
+- 使用框架基本功能（chain/pipeline）→ 2分
+- 实现了MCP/Function Calling协议 → 4分
+- 自定义Agent工具链、有深度框架定制 → 6分
 
-**开发工具链（2分）：**
-- IDE集成（VSCode插件/LSP/Webview面板等）→ 1分
-- CI/CD配置（GitHub Actions/Jenkins等）、监控/可观测性 → 1分
+**开发工具链（4分）：**
+- IDE集成（VSCode插件/LSP/Webview面板等）→ 2分
+- CI/CD配置（GitHub Actions/Jenkins等）、监控/可观测性 → 2分
 
-> 两项可叠加，上限5分
+> 两项可叠加，上限10分
+> 系统构建失败 → 本维度最高只得 3 分（工具链未落地为可运行成果）
 
 ---
 
-### 5. Agent核心能力（25分）
+### 5. Agent核心能力（30分）
 
 **4项硬性门槛条件（二进制判定，缺任意1个→整个维度0分）：**
 
@@ -111,62 +119,75 @@ AI框架集成深度 + 开发工具链。
 
 | 评分项 | 分值 | 评价基准 |
 |:-------|:---:|---------|
-| Agent存在性 | 4分 | 满足4个门槛条件→4分，缺任意1个→整个维度0分 |
-| 工具调用能力 | 6分 | 静态if-else工具选择→3分；动态prompt决策/多工具编排→6分 |
-| 自主规划能力 | 5分 | 有任务分解（script/model/Agent call）→3分；递归/动态重规划→5分 |
-| 协作机制 | 3分 | 多Agent通信（消息总线/共享memory）→3分；自主任务分配/协商→加分 |
-| 可靠性 | 4分 | retry+timeout→2分；fallback+降级策略→4分 |
+| Agent存在性 | 5分 | 满足4个门槛条件→5分，缺任意1个→整个维度0分 |
+| 工具调用能力 | 8分 | 静态if-else工具选择→4分；动态prompt决策/多工具编排→8分 |
+| 自主规划能力 | 6分 | 有任务分解（script/model/Agent call）→4分；递归/动态重规划→6分 |
+| 协作机制 | 4分 | 多Agent通信（消息总线/共享memory）→4分；自主任务分配/协商→加分 |
+| 可靠性 | 7分 | retry+timeout→3分；fallback+降级策略→7分 |
 
 > 所有评分必须引用具体代码文件和行号
+> 系统构建失败 → 本维度最高只得 10 分（Agent 能力须以可运行系统为载体）
 
 ---
 
-### 6. 实现完整度与稳定性（20分）
+### 6. 实现完整度与稳定性（35分）
+
+**评分优先锚定确定性证据（2026-08-27）：以下证据为系统客观检测所得，评分必须据此，不得被文档/README 声称覆盖：**
+- 构建结果（系统真实执行构建命令）
+- 启动/浏览结果（服务真实可访问）
+- 验收命令（README `## 验收` 块真实执行）
+- 功能发现轮（Map-Reduce 全量扫描：真实/部分/占位功能点统计）
 
 检查以下5项：
 
-1. 功能完整性（8分）
+1. 功能完整性（12分）
+   - **功能发现轮真实功能数**：≥10项→12分；5~9项→8分；1~4项→4分；0项→0分
    - 核心功能路径是否完整可运行
-   - 题目要求的全部功能是否实现
+   - 占位(stub)功能>30%→本项扣半；>50%→本项0分
 
-2. 构建可运行（4分）
-   - 项目能否正常构建（npm install/pip install/mvn compile等）
-   - 构建无报错
+2. 构建可运行（8分）
+   - 系统真实构建成功→8分；构建失败→0分（本项不证伪，未检测到构建系统视为构建失败）
+   - 构建有报错→按报错程度扣分
 
-3. 服务可启动（3分）
-   - 能否正常启动服务
-   - README步骤可直接运行
+3. 服务可启动（7分）
+   - 服务真实启动且可访问→7分；无法访问→0分
+   - 提交了 service_url 且评审期可访问→满分；CLI 形态服务可启动→满分
 
-4. 重试/降级机制（3分）
+4. 重试/降级机制（5分）
    - LLM调用是否有超时处理和重试
    - 是否有降级方案
 
-5. 错误处理（2分）
+5. 错误处理（3分）
    - 异常输入是否有明确提示
    - 错误信息是否友好
 
+> **硬性封顶（系统确定性判定）：构建失败 → 本维度最高只得 10 分。**
+
 ---
 
-### 7. 规模与功能点（20分）
+### 7. 规模与功能点（25分）
+
+**评分优先锚定确定性证据（2026-08-27）：功能发现轮统计（真实/部分/占位功能点）为规模判定的主要依据，README 声称仅作参考。**
 
 检查以下4项：
 
-1. 代码规模（5分）
-   - 基准分（每500行有效代码→0.5分，最多3分）
+1. 代码规模（6分）
+   - 基准分（每500行有效代码→0.5分，最多4分）
    - 语言多样性（3种以上语言→2分，1-2种→1分）
 
-2. 功能点覆盖（6分）
-   - 核心功能完整度
-   - 功能复杂度（CRUD vs 复杂业务逻辑 vs 算法实现）
-   - 重复代码>30%→扣3分，>50%→扣全部6分
+2. 功能点覆盖（10分）
+   - **功能发现轮真实功能数**：≥10项→10分；5~9项→7分；1~4项→3分；0项→0分
+   - 占位(stub)功能>30%→本项扣半；>50%→本项最高只给满分一半
+   - 核心功能完整度（对照 README/验收基准逐项核对功能发现清单）
+   - 重复代码>30%→扣3分，>50%→扣全部
 
-3. 可演示性（2分）
-   - 有启动配置（Dockerfile/scripts.start）→1分
-   - 有Web/CLI演示入口 →1分
+3. 可演示性（5分）
+   - 有启动配置（Dockerfile/scripts.start）→2分
+   - 有Web/CLI演示入口 →3分
 
-4. 数据与测试覆盖（2分）
-   - 有测试数据/样本 →1分
-   - 有测试覆盖且通过 →1分
+4. 数据与测试覆盖（4分）
+   - 有测试数据/样本 →2分
+   - 有测试覆盖且通过 →2分
 
 ---
 
@@ -199,11 +220,13 @@ AI框架集成深度 + 开发工具链。
 
 ---
 
-### 9. 演示与文档（10分）
+### 9. 演示与文档（8分）
+
+**前置约束（2026-08-27）：本维度考察文档质量本身，但不得超过「实现完整度与稳定性」维度得分——文档描述必须与真实可运行系统一致，假文档不得得高分。**
 
 检查以下4项：
 
-1. README完整性（3分）
+1. README完整性（2分）
    - 是否有README.md（若无→0分）
    - 是否包含：项目说明、安装步骤、使用示例
    - 是否包含：技术栈、依赖说明
@@ -215,63 +238,77 @@ AI框架集成深度 + 开发工具链。
 3. 启动与构建说明（2分）
    - 是否有明确的构建/启动命令
    - 是否有环境要求说明
+   - **README 声称的构建/启动命令与系统真实构建结果一致**（构建失败而 README 声称可运行 → 本项0分）
 
-4. 文档一致性（3分）
+4. 文档一致性（2分）
    - 文档描述与实际代码结构一致
    - 无过期/废弃文档
 
+> 系统构建失败 → 本维度最高只得 3 分（文档所述与系统真实状态不符）
+
 ---
 
-### 10. AI使用日志（5分）
+### 10. AI使用日志（10分）
+
+**优先锚定确定性审计（2026-08-27）：系统对日志做占位率审计（占位>50%→本维度封顶），评分必须参考审计结果。**
 
 检查以下3项：
 
-1. AI使用记录（2分）
-   - 有CLAUDE.md/AGENTS.md等文件记录AI协作方式 → 2分
-   - 仅有skill/agent配置但无使用记录 → 1分
+1. AI使用记录（4分）
+   - 有CLAUDE.md/AGENTS.md等文件记录AI协作方式 → 4分
+   - 仅有skill/agent配置但无使用记录 → 2分
    - 完全无任何AI相关文件 → 0分
 
-2. 调用细节（2分）
+2. 调用细节（4分）
    - 记录了每次AI调用的时间、模型、目的
    - 记录了prompt原文
 
-3. 真实性验证（1分）
+3. 真实性验证（2分）
    - 日志内容与代码提交历史一致
    - 无伪造/编造的日志条目
 
 【交叉验证规则】
 - AGENTS.md声称的"使用了XX技术"，必须在代码中找到对应的配置或实现文件，否则扣2分
 - 声称"调用细节记录了prompt原文"但文件内容为空或只有模板文案 → 视为不实，扣2分
+- **系统确定性审计：日志占位率>50% → 本维度封顶至满分的30%**
 
 ---
 
-### 11. 效果与数据（20分）
+### 11. 效果与数据（25分）
+
+**评分优先锚定确定性证据（2026-08-27）：系统真实运行测试为准，README 自报数据不作数。**
 
 检查以下5项：
 
-1. 测试覆盖（5分）
+1. 测试覆盖（6分）
    - 是否有单元测试（若无→0分）
    - 测试是否覆盖核心功能路径
+   - **系统真实执行测试的结果（通过数/总用例）为评分依据，无真实测试结果→本项0分**
 
-2. 测试工具与框架（3分）
+2. 测试工具与框架（4分）
    - 是否使用标准测试框架（pytest， jest, JUnit等）
    - 是否有自动化测试配置（CI、pre-commit等）
 
-3. 效果验证数据（4分）
-   - 是否有性能基准、正确性验证数据
+3. 效果验证数据（5分）
+   - 是否有性能基准、正确性验证数据（系统真实测得）
    - 是否有对比数据（如AI生成vs手写对比）
+   - **纯增益/提效类指标必须有基线对比数据，仅自报无基线→C档封顶**
 
-4. 覆盖率报告（4分）
+4. 覆盖率报告（5分）
    - 是否有覆盖率报告（如gcov， coverage.py, jest --coverage）
-   - 覆盖率≥80%→4分，≥50%→2分，<50%→0分
+   - **系统真实解析的覆盖率**：≥80%→5分，≥50%→3分，<50%→1分，无→0分
 
-5. 测试结果可复现（4分）
+5. 测试结果可复现（5分）
    - 测试环境配置明确
    - 测试数据随仓库提供（非外部依赖）
+   - **系统可重复执行测试且通过→5分；测试失败→2分；不可运行→0分**
+
+> **硬性封顶（系统确定性判定）：测试执行失败 → 本维度最高只得满分的50%；构建失败 → 最高只得 8 分。**
+> **效果类数据缺位（无测试/无覆盖率/无基准）→ C档封顶至满分的30%。**
 
 ---
 
-### 12. 安全性（10分）
+### 12. 安全性（9分）
 
 检查以下4项：
 
@@ -287,10 +324,12 @@ AI框架集成深度 + 开发工具链。
    - 日志中不输出敏感信息
    - 错误页面不暴露内部路径
 
-4. 依赖安全（2分）
+4. 依赖安全（1分）
    - 无已知漏洞的依赖
    - 依赖版本明确
 
+> 系统构建失败 → 本维度最高只得 3 分（无法验证运行期安全性）
+
 ---
 
 ## 合格判定