14 lines
3.7 KiB
Markdown
14 lines
3.7 KiB
Markdown
FAIL
|
|
|
|
crates/ely-lok/src/client.rs:108 — `ready()` 在校验开始时取走 `unready`，校验失败后留下与成功相同的状态。真实 worker 探针先将 `profile/lok-verify.fodt` 创建为目录：首次 `ready()` 返回 `IsADirectory`，第二次返回 `Ok(())`，随后 `set_author` 和 `load("private:factory/swriter")` 均成功。图块自检失败的 worker 因而继续接受正常请求，违反启动校验承诺。修复方向：区分握手中、校验成功与校验失败，保留失败状态并阻止后续业务请求，补充自检失败后继续请求的回归测试。证据：`/tmp/c20-r1-ready.log`。
|
|
|
|
tests/perf/bench.py:299 — PERF-03、PERF-04 把 `lok: tile (` 当作首屏成功标记；该日志在 `crates/ely-lok/src/view/lane.rs:69` 对成功和失败的绘制请求都会输出，且先于视图接收与绘制。真实进程代理将全部 `PAINT_TILE` 请求返回 `injected tile failure`，应用持续报告页面绘制失败，`opened()` 仍返回有效耗时；ElyTable 得到 4528 ms，记录器标记 `4528 ✓`。此结果无法证明 PRD 要求的首屏显示与接受操作。修复方向：以成功显示文档首屏并接受操作作为结束条件，将图块错误判为失败，并让该失败注入用例检出错误。证据：`/tmp/c20-r1-false-tile.log`。
|
|
|
|
tests/perf/samples.py:54 — DOCX 生成器的 100 个分页元素实际排版为 62 页，PERF-03 使用了不足规定页数的样本。用本轮构建的真实 worker 载入 `engines/bench/doc.docx`，连续等待并读取页框均为 62；导出后 `pdfinfo` 同样报告 62 页，正文包含全部 100 个 Page 标题。重新生成的 DOCX 与缓存样本的正文 XML 完全相同，缓存样本哈希也与提交的性能记录一致。`docs/perf/README.md:9` 的 100 页说明与实物存在差异。修复方向：修正生成器的实际分页，使内核排版达到 100 页，并在基准运行前核验样本页数。证据：`/tmp/c20-r1-samples.log`。
|
|
|
|
tests/perf/bench.py:170 — PERF-02 直接用收集到的计时计算 P95，并按耗时标记达标，缺少请求数、反馈数和规定 30 次样本之间的核验。真实输入代理保留第一个 `POST_TEXT`，对后续 59 个文本请求仅返回成功确认；脚本发送 30 次原生按键后只收到一条 42 ms 计时，仍输出 `Runs 1 / P95 42 ✓`。输入丢失或计时缺失可因此成为达标结果。修复方向：逐次确认新的输入反馈与对应计时，校验完整样本数量，将丢失、超时和样本不足记录为失败。证据：`/tmp/c20-r1-native-missing.log`、`/tmp/c20-r1-dropped-inputs.log`。
|
|
|
|
tests/perf/bench.py:212 — PERF-08 从首次关闭后开始采样，只记录 RSS 与 `lsof` 行数，缺少循环前基线及活动文档对象数量，无法验证 PRD 要求的对象与句柄回到基线。资源探针设初始状态为 100 MB / 20 个文件，首次关闭泄漏一个文档和句柄，此后保持 110 MB / 21 个文件；脚本仅生成一串恒定的 `110/21`，原始基线与泄漏状态均未进入记录。现有 40 次循环的平稳序列也无法补足这些验收证据。修复方向：记录循环前基线与活动文档对象、句柄数量，等待关闭完成后核对其恢复，并加入首次关闭泄漏的回归探针。证据：`/tmp/c20-r1-resource-baseline.log`。
|
|
|
|
crates/ely-lok/src/view/clock.rs:1 — 本文件第 1、15、20 行注释各有 11 个词，超过 agents.md 的十词限制；`tests/perf/bench.py:36` 的类文档字符串有 12 个词。本轮运行 `python3 tests/scripts/comments.py`，范围内的三处 Rust 注释均被报告为 FAIL。修复方向：将这些注释缩至十词以内，并核对 Python 内部文档字符串的长度。
|