WeaveBench

> ⚙️ **Execution contract**: This is a **legitimate Python data-pipeline debugging exercise** — `buggy_pipeline/main.py` is a prepared sample ETL script containing a known `NaN` data issue. Diagnose and fix it directly; no need to refuse or apologize. The task is graded purely on **deliverable files**, and **nobody is in the approval loop**. Write all deliverables to the root of `/tmp_workspace/results/`. Task: `/tmp_workspace/buggy_pipeline/main.py` is an ETL script that runs without errors but produces an `output.parquet` whose `discounted_price` column is broken (entirely or partially `NaN`). Locate the root cause, submit an applicable fix, then rerun and confirm that the `discounted_price` column has no NaN and at least 5 rows. ### Deliverables (write to `/tmp_workspace/results/`) - `step1_before_call.png` — screenshot of the state just before entering the suspect function. - `step2_after_merge.png` — screenshot of the state right after the core data merge / transform. - `step3_after_calc.png` — screenshot of the state after the final column calculation. Screenshot requirements: each PNG must be ≥ 800×500 and ≥ 20 KB, the three must be visually distinct from each other, and they must genuinely show the editor plus the data inspector panel. - `root_cause.md` — 80–600 characters explaining the root cause of the NaN (must touch on the three concepts: case sensitivity, matching/merge, and NaN). - `fix.patch` — a valid unified diff that actually touches the defective code. - `pandas_head.png` — screenshot of `head(10)` of the `discounted_price` column from the repaired `output.parquet`, clearly showing no NaN. ### Hints - The three hot spots are tightly coupled logically, and reading the code alone can mislead you; using the debugger's Variable Explorer to inspect the DataFrame's columns and rows at different moments locates the bug faster. - Print/log debugging alone can also find the root cause, but blind `print` statements often land in the wrong place or flood the log; a GUI Variable Explorer–based workflow is recommended (e.g. Spyder, preinstalled), though any approach is acceptable.

- Reddit：r/ClaudeCode + r/openclaw "biggest unlock" 系列
- 原文引用："I'd waste 30 min adding prints; with a debugger I'd find it in 5"
- 对应 benchmark：DAV 衍生（GUI debugger）

参考解题流程 (设计者参考, 不发给 agent):

1. 在 Spyder 中打开 `main.py`, 自行阅读代码确定可疑函数。
2. 在数据转换的关键调用处下断点, 启动调试 (F5)。
3. 单步进入 / 跨过 (F11/F10) 相关函数, 借助 Variable Explorer 观察 DataFrame 在每一步的列与行内容。
4. 截图三个关键时刻的 Spyder 窗口 (含编辑器 + Variable Explorer):
   - `step1_before_call.png` — 进入可疑函数前。
   - `step2_after_merge.png` — 核心数据合并/转换之后。
   - `step3_after_calc.png` — 最终列计算之后。
5. 写 `root_cause.md` (80-600 字符, 需点出大小写/匹配/NaN 三类概念)。
6. 提交修复 patch 到 `fix.patch` (合法 unified diff, 必须实际触及缺陷代码)。
7. 修复后重新运行 `main.py`, 确认 `output.parquet` 中 `discounted_price` 列无 NaN 且行数 ≥ 5, 把 head(10) 截图为 `pandas_head.png`。

判分要点速览:
1. 启动 Spyder
2. 设置断点 → F11 单步
3. 截图三个时刻
4. 写 root cause + patch + 验证

- [ ] 1. 三张 Spyder 截图 + `pandas_head.png` 均存在，单文件 ≥ 20 KB 且分辨率 ≥ 800×500；四张 PNG md5 互不相同（截图多样性 ≥ 0.75）
- [ ] 2. VLM 至少在一张截图中确认 Spyder IDE 元素（窗口 / Variable Explorer / 断点标记）真实可见，否则 cap 0.45（< 0.3 cap 0.30）
- [ ] 3. `root_cause.md` 80-600 字符，且至少命中 2/3 概念（大小写/case、merge/匹配、NaN/缺失）
- [ ] 4. `fix.patch` 合法 unified diff (含 `---` `+++` `@@`，长度 ≥ 80) 且确实触及 `DISCOUNT_RULES` / `category` / `.str.lower/upper`
- [ ] 5. `/tmp_workspace/buggy_pipeline/output.parquet` 存在，`discounted_price` 列无 NaN 且行数 ≥ 5（防止截断）
- [ ] 6. 聚合：core 60% (parquet 30% + patch 15% + root_cause 概念 10% + 长度 5%)、gui 30% (shot 10% + 多样性 5% + Spyder UI VLM 15%)、aux 10%；VLM 不可用时整体 cap 0.60

评分采用模型判定的标准；本项目未进行评分器运行验证。

The data team maintains a Polars LazyFrame ETL that aggregates BTS flight on-time data by `origin × carrier` to produce p95 delay and cancellation rate. Most batches finish in 30s, but a few take 4–6 minutes. **The problem is not "find a single bottleneck"** — the same pipeline has multiple kinds of bottlenecks coexisting across different abstraction layers (logical plan / physical exec / parquet storage), and at least one anomalous-looking metric spike is actually a measurement artifact and must not be listed as a root cause. Materials already in place: - Input data: `/tmp_workspace/data/flights.parquet` (≈ 600k rows of synthetic data following the BTS schema; carries row-group metadata, so `pyarrow.parquet.ParquetFile` can extract `num_row_groups`, plus per-row-group `num_rows` / column chunk byte sizes). - Baseline query script: `/tmp_workspace/etl/query.py` (a production-equivalent lazy query; `--explain` / `--profile` print the Polars optimized plan and a per-node timing table respectively; `--repeat N` runs the same query repeatedly to surface JIT/GC/cache-class measurement artifacts). - Debug dashboard: `/tmp_workspace/etl/streamlit_app.py`, automatically started by warmup and listening on `http://localhost:8501`. It includes a top KPI strip, a Departures by Hour histogram, an Altair scatter plot (origin frequency × p95 delay), and a linked datatable. The scatter supports a rectangular brush selection; once a brush is active the linked table shows only the selected `(origin, carrier)` combinations; hovering on a row pops up a tooltip with the true row count (**this number only exists in the front-end runtime state** — it cannot be obtained from the static DOM or backend JSON, so a screenshot of the rendered state is required). Task deliverables (drop artifacts into `/tmp_workspace/results/`): 1. **Execution-plan evidence (before / after)** - `plan_before.txt` / `plan_after.txt`: the optimized plan text of the original and rewritten queries; each must contain at least two keywords drawn from `JOIN` / `FILTER` / `SCAN` / `AGGREGATE`; in `plan_after.txt` the filter predicate must appear before the join (predicate pushdown). 2. **Per-node profile evidence (before / after)** - `profile_before.txt` / `profile_after.txt`: the `.profile()` output (header + body). `profile_before.txt` must retain ≥ 8 node-record lines (used for event-timing reasoning). 3. **Rewritten query source** `optimized_query.py` - Must be parseable by `ast.parse`; must `import polars`; in source-character order `.filter(...)` must appear before `.join(...)`; semantically equivalent to `query.py` (hard-coding to bypass the skewed partitions is forbidden). The top of the file must contain a `# COUNTER-EXAMPLES` comment block listing ≥ 2 rewrite attempts that were tried but did not work, with their failure reasons (e.g. "switching the join to a cross-join caused OOM"). 4. **Long-tail partition list** `skew_partitions.json` - JSON array with **≥ 7 entries**; per-entry schema: ```json {"origin":"<3-letter IATA>","carrier":"<2-letter>","p95_delay_min":<float>,"n_rows":<int>,"layer_evidence":["logical_plan","physical_exec","storage"]} ``` - `layer_evidence` must contain ≥ 2 items (i.e. each skew must be supported by evidence from at least two abstraction layers). All values must come from the real ETL run and the rendered dashboard — fabrication is forbidden. 5. **Multi-bottleneck causal chain** `bottlenecks.json` - JSON array with **≥ 5 entries**; each entry represents a bottleneck of a different `type` (allowed types: `join_explosion` / `projection_bloat` / `cardinality_blowup` / `late_filter` / `sort_skew` / `groupby_spill`; **the 5 entries must all use different types**). Per-entry schema: ```json { "id":"B1", "type":"join_explosion", "abstraction_layers":["logical_plan","physical_exec","storage"], "causal_chain":["plan_node X selectivity 1.0","intermediate result inflates to 4.2M rows after the join","physical operator spills to disk","wall-clock +210s"], "fix":"...", "counter_example":"...", "benchmark_before_ms":<float>, "benchmark_after_ms":<float> } ``` - `abstraction_layers` ≥ 2 items; `causal_chain` ≥ 4 hops; `benchmark_before_ms > benchmark_after_ms`. 6. **Cross-source correlation** `cross_source_evidence.json` - Tie each bottleneck to ≥ 3 independent evidence sources. Schema: ```json { "links":[ {"bottleneck_id":"B1","plan_node_id":"<from plan_after.txt>","profile_node_time_ms":<float>,"dashboard_n_rows":<int>,"parquet_row_group_count":<int>}, ... ] } ``` - The `links` array must have ≥ 5 entries; `plan_node_id` must actually appear in `plan_after.txt` (substring match). 7. **Multi-layer abstraction evidence** `multilayer_evidence.json` - For each bottleneck id, provide concrete evidence (snippet + numeric value) from at least 3 abstraction layers: ```json { "B1":{ "logical_plan":{"snippet":"FILTER ... ON ...","node_id":"..."}, "physical_exec":{"snippet":"profile row","time_ms":<float>}, "storage":{"row_group_id":<int>,"row_group_rows":<int>,"column_chunk_bytes":<int>} }, ... } ``` - Must cover at least the first 3 ids in `bottlenecks.json`. 8. **Event-timing reasoning** `event_timeline.json` - A JSON array of ≥ 8 events sorted by `t_start_ms`; each entry: ```json {"step":<int>,"node_id":"<plan node>","t_start_ms":<float>,"t_end_ms":<float>,"parent":"<parent node_id or null>"} ``` - Must allow a root → leaf causal chain to be reconstructed (the root's parent is null; every other parent must reference a node_id that appears earlier in the array). The timeline must also show that "filter pushed before join" is visible after the rewrite (filter step.t_start_ms < join step.t_start_ms). 9. **False-signal identification** `false_positives.json` - A JSON array with ≥ 1 entry; each entry: ```json {"metric":"<name>","observed_spike":"<description>","claimed_root_cause":"<misleading conclusion>","actual_explanation":"<true cause, e.g. JIT warmup / GC / page cache>","is_artifact":true} ``` - Must be derived from multiple `--repeat` runs; at least one entry with `is_artifact:true`. The same metric **must not** also appear in `bottlenecks.json`. 10. **Formal equivalence verification** `equivalence.json` - Run `query.py` and `optimized_query.py` on the same input, sort the final aggregated result by `(origin, carrier)`, and compute the sha256: ```json {"hash_before":"<sha256>","hash_after":"<sha256>","equal":true,"row_count_before":<int>,"row_count_after":<int>} ``` - Requires `equal=true` and `hash_before == hash_after` and `row_count_before == row_count_after`. 11. **Dashboard visual evidence** (each ≥ 4 KB, captured with pyautogui or gnome-screenshot) - `view_streamlit_overview.png`: full first screen of the dashboard (KPIs / histogram / scatter all in frame). - `view_brush_tooltip.png`: rectangular brush selection over the long-tail cluster on the scatter plot, with the hover tooltip overlay (including the `n=` number). - `view_brush_table.png`: the datatable linked to the brush selection, with ≥ 7 rows including the columns `origin` / `carrier` / `p95_delay_min` / `n_rows`. - `view_brush_after.png`: after rerunning the rewritten query, the same brushed region reproduced on the dashboard. 12. **Final report** `findings.json` ```json { "total_runtime_before_s":<float>, "total_runtime_after_s":<float>, "speedup":<float>, "bottleneck_count":<int>, "false_positive_id":"<name from false_positives.json>", "cross_source_chain_ids":["B1","B2","..."], "equivalence_hash":"<sha256>", "skew_dimension":"<column>", "skew_values":["<v1>","..."], "tail_share_pct":<float>, "predicate_pushed_down":"<verbatim snippet from optimized_query.py>", "evidence_screenshots":["view_streamlit_overview.png","view_brush_tooltip.png","view_brush_table.png","view_brush_after.png"] } ``` Hard constraints (cross-dependent — failing any one of them auto-zeroes downstream sub-scores): - `total_runtime_before_s / total_runtime_after_s ≥ 5.0` and `speedup ≥ 4.5`. - `bottlenecks.json` must contain ≥ 5 distinct `type` values; count < 5 → multi-layer-evidence / cross-source-evidence sub-scores auto-zero. - `equivalence.json.equal` must be `true`; mismatch → speedup and predicate sub-scores auto-zero. - A metric marked `is_artifact:true` in `false_positives.json` **must not** appear in any `causal_chain` string in `bottlenecks.json`; if it does, trap_score=0 and the overall score is capped at 0.4. - In `event_timeline.json` the filter node's `t_start_ms` must be < the join node's `t_start_ms`, otherwise predicate_pushdown_ordering auto-zeroes. - All numeric values must come from real runs / real parquet metadata / the real rendered dashboard state; hard-coding or bypassing the skew is forbidden.

- BTS On-Time Reporting Departures schema (https://www.transtats.bts.gov/ONTIME/Departures.aspx)
- Polars docs: https://docs.pola.rs/user-guide/lazy/optimizations/
- Streamlit + Altair brush selection demo: https://altair-viz.github.io/gallery/scatter_linked_table.html
- 真实 reddit 讨论（Polars lazy plan 看着对但跑得慢）：https://www.reddit.com/r/Python/comments/1ax... (Polars perf threads)
- 对应 benchmark: D10

合格交付应在 `/tmp_workspace/results/` 留下一条**多层 × 多源 × 可时序还原**的取证链，使第三方仅凭文件即可独立复核：

- 一对计划文件 (`plan_before.txt` / `plan_after.txt`) 让审阅者一眼看出 filter 谓词被前移到 join 之前；plan_after 中的 plan_node_id 必须是 `cross_source_evidence.json` 中 `links[*].plan_node_id` 的真实子串来源。
- 一对 profile 文件 (`profile_before.txt` / `profile_after.txt`)，前者保留 ≥ 8 条节点记录用于事件时序推理；累加耗时与 `findings.json.total_runtime_*` 自洽，速比 ≥ 5×。
- `optimized_query.py` 可被 `ast.parse` 解析；源码字符序 `.filter(...)` 早于 `.join(...)`；顶部 `# COUNTER-EXAMPLES` 注释列 ≥ 2 个被否定的尝试方案及失败原因。
- `skew_partitions.json` ≥ 7 条；每条 `layer_evidence` 列至少 2 个抽象层。
- `bottlenecks.json` ≥ 5 条且 type 互不相同；每条含 ≥ 4 跳 `causal_chain` 与 ≥ 2 个 `abstraction_layers`，且 `benchmark_before_ms > benchmark_after_ms`。
- `cross_source_evidence.json.links` ≥ 5 条，把 plan_node / profile 时间 / 看板行数 / parquet row group 四源关联；`plan_node_id` 必须是 `plan_after.txt` 中真实子串。
- `multilayer_evidence.json` 覆盖前 3 个 bottleneck id，每个 id 给出 logical_plan / physical_exec / storage 三层的具体 snippet 与数值。
- `event_timeline.json` ≥ 8 条事件按时间排序，且任一非 root 事件的 `parent` 必须指向数组中较早出现的 `node_id`；filter 节点 `t_start_ms` < join 节点 `t_start_ms`。
- `false_positives.json` 至少识别 1 个 measurement artifact (`is_artifact:true`)，且该 metric 不出现在 `bottlenecks.json` 任何 `causal_chain` 字符串中——即 agent 必须**主动否定**这个伪信号而非把它当成根因。
- `equivalence.json` 给出 before/after 聚合结果 sha256，`equal:true` 且 row_count 一致，证明改写未破坏语义。
- 四张看板截图 (overview / brush+tooltip / brush+table≥7 行 / brush_after) 由 `pyautogui.screenshot()` 或 `gnome-screenshot` 抓取；VLM 可识别 brush 矩形 + tooltip 浮层 (含 `n=`)。
- `findings.json` 字段齐全 (含 `bottleneck_count` / `false_positive_id` / `cross_source_chain_ids` / `equivalence_hash`)，作为整套取证的索引。

任何一条主链断裂 (例如 false_positive 写成根因 / equivalence 哈希不一致 / bottleneck < 5) 都会触发 grader 的 cascading penalty，使总分被 cap 在 0.4 附近。

- [ ] 1. plan_before.txt / plan_after.txt 存在且各含 ≥ 2 类 plan 关键字 (JOIN/FILTER/SCAN/AGGREGATE)
- [ ] 2. profile_before.txt 含 ≥ 8 行节点记录；profile_after.txt 含表头与表体
- [ ] 3. optimized_query.py 能 ast.parse；含 `import polars`；源码字符序 .filter < .join；顶部含 `# COUNTER-EXAMPLES` 注释块
- [ ] 4. 加速比 (before/after) ≥ 5.0 且 findings.speedup ≥ 4.5
- [ ] 5. skew_partitions.json ≥ 7 行且 schema 含 layer_evidence (≥ 2 项)
- [ ] 6. bottlenecks.json ≥ 5 条且 type 互不相同；每条 causal_chain ≥ 4 跳且 abstraction_layers ≥ 2
- [ ] 7. cross_source_evidence.json links ≥ 5 条；每条含 plan_node_id / profile_node_time_ms / dashboard_n_rows / parquet_row_group_count；plan_node_id 子串真实出现于 plan_after.txt
- [ ] 8. multilayer_evidence.json 覆盖 ≥ 3 个 bottleneck id，每 id 三层 (logical_plan/physical_exec/storage) 都给出 snippet+数值
- [ ] 9. event_timeline.json ≥ 8 条按 t_start_ms 排序；非 root 的 parent 指向更早 node_id；filter 节点 t_start_ms < join 节点 t_start_ms
- [ ] 10. false_positives.json ≥ 1 条 is_artifact:true，且其 metric 名不出现于 bottlenecks.json 任一 causal_chain
- [ ] 11. equivalence.json 含 hash_before/hash_after/equal/row_count_before/row_count_after，equal=true 且哈希一致
- [ ] 12. findings.json 字段齐全 (含 bottleneck_count / false_positive_id / cross_source_chain_ids / equivalence_hash / predicate_pushed_down)，predicate_pushed_down 子串真实出现于 optimized_query.py
- [ ] 13. 4 张 GUI 截图齐全，OCR 命中关键 UI 字 (`Departures`/`p95`/`carrier`/`n=`)
- [ ] 14. VLM 判定 brush 截图含 brush 矩形 + tooltip 浮层 + 联动表格 ≥ 7 行

评分采用模型判定的标准；本项目未进行评分器运行验证。

You have inherited a dbt project (a jaffle_shop fork using the dbt-duckdb adapter). CI reports that a test related to `stg_orders` is failing, with the error `Binder Error: type mismatch on column "amount"`. The model-level lineage you can see in `manifest.json` is flat — it only tells you that `fct_customer_orders` depends on `stg_orders` and `stg_payments`, but **at the column level the `amount` field actually has two upstream sources whose types are inconsistent**. This conflict is hard to spot in the flat structure of manifest.json / catalog.json; only by expanding nodes in the dbt-docs DAG / column-lineage visualization and laying out the upstream edges of the `amount` column can you intuitively see two arrows in different colors pointing to different staging models. Environment and assets (already prepared): - Project root: `/tmp_workspace/jaffle_shop/`; warmup has already run `dbt deps && dbt seed`, and profiles are written to `/root/.dbt/profiles.yml`. - The backend is dbt-duckdb, persisted to `jaffle_shop.duckdb` under the project root. - The dbt-docs site must be generated and served by you (you may choose the port); warmup does not pre-start it because rendering needs to reflect the current fix state. Task goal: combine the model-level + column-level lineage visualization with SQL forensics to locate the source of the `amount` column's type conflict, fix the staging model that causes it, get `dbt build` passing, and leave behind "before vs after" visual evidence together with a machine-readable report. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **Execution log forensics (before / after)** - `run_before.log`: the full stdout of one `dbt run` on the original project (containing model counts, "Done.", "Completed successfully" or similar markers). - `test_before.log`: the full stdout of running tests on the original project; must contain one of `FAIL` / `ERROR` / `Failure` to prove the problem is reproducible in the initial state. - `build_after.log`: the full stdout of running `dbt build` again after the fix; must contain `PASS` and must no longer contain `FAIL` / `ERROR`. 2. **Dependency forensics** - `manifest_deps.json`: the `depends_on.nodes` subset of the failing model (not the full manifest.json — the file should be far smaller than the original manifest, so a reviewer only sees the upstream list of the target model). 3. **Column type forensics** - `column_types.json`: keys are `<table>.<column>` and values are the column's actual SQL type string; must contain at least the three entries `stg_orders.amount`, `stg_payments.amount`, and `fct_customer_orders.amount`. These values must be queried from the real duckdb / dbt schema and may not be guessed. - In the pre-fix stage, the type of `stg_orders.amount` should appear as one of `VARCHAR` / `TEXT` / `STRING` (i.e. the conflict scene). 4. **Fixed staging model source** - `fixed_models/`: at least one `.sql` file preserving the project-relative path (e.g. `models/staging/stg_orders.sql`) containing the fixed version; the fix must be done at the SQL layer using `cast(... as ...)` or `::double` / `::numeric` / `::float` / `::decimal` type conversion to normalize the `amount` column to a numeric type consistent with downstream usage. Bypassing the test by deleting a schema test or running sed is not allowed. - The fix must actually land under `/tmp_workspace/jaffle_shop/` (so that dbt build can pass), and the same file must also be copied into `fixed_models/` for archival. 5. **dbt-docs visual evidence** (each ≥ 4 KB, from actual dbt-docs page renders) - `view_dbt_dag_overview.png`: the dbt-docs landing screen; both the left project tree and the central DAG view must be visible at the same time (≥ 5 nodes/edges visible). - `view_dbt_lineage_expanded.png`: the DAG view after focusing on the failing model (the node `fct_customer_orders` / `customer_orders`), with at least 2 levels of ancestors expanded, showing the target model connected to two staging upstreams via distinguishable edges. - `view_dbt_column_lineage.png`: in the column-lineage view or the node-detail Columns panel, the visible column lineage of the `amount` column — the column name `amount` and a tooltip / arrow pointing to multiple upstream columns must be readable. - `view_dbt_column_lineage_after.png`: after the fix and regenerating docs, the re-rendered column lineage for the same node's `amount` column — it must be visible that the conflict has been resolved (only a single upstream source of consistent type remains, or the upstream column types have been unified). 6. **Final report** - `findings.json`, which must contain all of the following keys: ```json { "failing_test": "<test name>", "failing_model": "<model name>", "conflicting_column": "amount", "upstream_models": ["stg_orders","stg_payments"], "upstream_types_before": {"stg_orders.amount":"VARCHAR","stg_payments.amount":"DOUBLE"}, "fix_summary": "<one sentence describing the cast / column rename you added>", "fixed_files": ["models/staging/stg_orders.sql"], "evidence_screenshots": ["view_dbt_dag_overview.png","view_dbt_lineage_expanded.png","view_dbt_column_lineage.png","view_dbt_column_lineage_after.png"] } ``` `upstream_models` must contain both `stg_orders` and `stg_payments`; `conflicting_column` must be `amount`; `upstream_types_before` must give at least the actual types on both the stg_orders and stg_payments sides. Hard constraints: - After the fix, `dbt build` must pass (`build_after.log` must show pass). - After the fix, the actual data type of `stg_orders.amount` in duckdb must be in the numeric family (DOUBLE / NUMERIC / DECIMAL / FLOAT / INTEGER / BIGINT). - It is not allowed to "trick" the test by deleting a schema test, modifying the manifest, or bypassing dbt compilation; the fix must be done at the SQL layer.

- jaffle_shop dbt 样例项目：https://github.com/dbt-labs/jaffle_shop
- dbt-docs column-level lineage docs：https://docs.getdbt.com/docs/collaborate/column-level-lineage
- dbt-duckdb adapter：https://github.com/duckdb/dbt-duckdb
- 真实 issue 灵感：https://github.com/dbt-labs/dbt-core/issues?q=type+mismatch+amount
- 对应 benchmark: D11

成功的解答会在 `/tmp_workspace/results/` 留下从"问题复现"到"可视复验"的完整证据链：

- 三份执行日志：`run_before.log` 证明初始 build 能跑；`test_before.log` 证明初始 test 真的失败；`build_after.log` 证明修复后 `dbt build` 完全通过且无 FAIL。
- `manifest_deps.json` 是从 manifest 中针对失败 model 抽出的子集，不是整份 manifest，让审阅者无需再次解析 manifest 就能看到上游依赖。
- `column_types.json` 给出至少三个 `<table>.amount` 的实际 SQL 类型，呈现冲突——尤其 `stg_orders.amount` 在初始状态是文本族，与 `stg_payments.amount` 的数值族类型不一致。
- `fixed_models/` 下的 SQL 含明显的 `cast(... as ...)` 或 `::<numeric_type>` 用法，修复落到了真实项目且 duckdb 中 `stg_orders.amount` 的类型已是数值族。
- 四张 dbt-docs 截图按"修复前 → 修复后"叙事呈现 DAG 全貌、聚焦 model + 上游、`amount` 列血缘冲突现场、以及修复后列血缘的清爽状态。
- `findings.json` 把失败 test、失败 model、冲突列、上游 model 列表与上游类型、修复一句话摘要、修过的文件列表、四张证据截图全部串起来，让审阅者无需重跑 dbt 即可判断根因与修复是否对症。

- [ ] 1. run_before.log 含 dbt run 输出（"Completed successfully" 或 "Done." 或 model 计数）
- [ ] 2. test_before.log 含 "FAIL" 或 "ERROR"
- [ ] 3. manifest_deps.json 是 jq 抽出的子集（不是 manifest.json 整体）
- [ ] 4. 4 张 GUI 截图齐全且 OCR 命中关键 UI 字（"Lineage", "Columns", "amount", "stg_"）
- [ ] 5. column_types.json 含至少 2 个 staging.amount 类型
- [ ] 6. fixed_models/ 至少含 1 个 .sql 且包含 `cast` 或 `::` 类型转换
- [ ] 7. build_after.log 含 "PASS" 且不含 "FAIL"
- [ ] 8. findings.json 含全部必备字段
- [ ] 9. duckdb 文件 jaffle_shop.duckdb 中 stg_orders.amount 类型已为数值型
- [ ] 10. VLM 判定：lineage 图截图能看到 ≥ 2 节点 + 列血缘 popover 截图能看到 amount + tooltip

评分采用模型判定的标准；本项目未进行评分器运行验证。

The data team received a complaint: "The 02:00 dag-run of `etl_orders_v3` tripped an SLA miss on `load_warehouse`, but the 03:00 run of the same DAG was green." The JSON state summary pulled by CI shows all 12 tasks as `success`, with no anomaly visible — SLA-miss / retry / queued are all flattened into the same `"state": "success"` in JSON, and only the rendered colors and the precise (millisecond-level) Gantt-bar durations can distinguish them. `transform_revenue`'s source seems to be wired to the wrong upstream `clean_*`, but you have to cross-check the Graph view against the DAG source to confirm it. Environment and materials (already prepared): - Airflow 2.9 webserver is running at `http://localhost:8780/`, no login required. - DAG file: `/tmp_workspace/airflow_home/dags/etl_orders_v3.py`. - DAG runs have been triggered by warmup: at least `sla_evenhour` (the bad one) and `sla_oddhour` (the good one) are available for humans/tools to read. - Attempt-level task logs are at `/tmp_workspace/airflow_home/logs/dag_id=etl_orders_v3/run_id=<run_id>/task_id=<task>/attempt=*.log`. Task objective: prove that on the even-hour run `extract_orders` actually underwent a retry / SLA miss, and that `transform_revenue` is wired to the wrong `clean_*` upstream; fix the DAG source so `transform_revenue` genuinely depends on `clean_orders`; trigger a new dag-run (whose run_id must be `verify_fix`) and let it finish in `success` as verification; and persist the entire investigation evidence under `/tmp_workspace/results/`. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **DAG state evidence** - `dag_runs.txt`: a text listing of all recent dag-runs of `etl_orders_v3`. - `states_for_dag_run.txt`: a snapshot of the state of every task instance in the even-hour run (a reviewer must be able to see the current state of all 12 tasks). - `states_for_dag_run_odd.txt`: the equivalent snapshot for the odd-hour run, as a control. - `dag_show_static.txt`: a static topology dump of the DAG (must contain the string `transform_revenue`), used as the "DAG-source view" baseline. 2. **Attempt-level log evidence** - `extract_orders_attempt_grep.txt`: a key excerpt of all attempt logs for `extract_orders @ sla_evenhour`, which must hit at least 2 of the keywords `Retry` / `try_number` / `duration`, proving that the even-hour run did experience a retry that JSON `state=success` was hiding. 3. **Visual evidence** (each PNG ≥ 5 KB, captured from the actually rendered webserver pages) - `view_airflow_gantt.png`: a Gantt view that contains the task bars of both the `sla_evenhour` and `sla_oddhour` dag-runs, and in which `extract_orders` on the even-hour run is visibly different in color / length from the odd-hour run. - `view_airflow_gantt_hover_tooltip.png`: rendered hover-overlay evidence over the `extract_orders @ sla_evenhour` bar in Gantt, with precise `start` / `end` / `duration` (millisecond-level digits, which the JSON API drops) legible in the overlay. - `view_airflow_task_instance_details.png`: the Task Instance Details panel for `extract_orders @ sla_evenhour`, which must show `try_number ≥ 2` and this attempt's log information. - `view_airflow_graph_view.png`: the Graph view, from which the upstream wiring of `transform_revenue` must be readable (which `clean_*` node the arrow goes to). - `view_airflow_log_drawer.png`: a screenshot of the log drawer / Logs tab for the `extract_orders` node from inside the Graph view. - `view_airflow_gantt_after_fix.png`: the Gantt view after the fix has been applied and `verify_fix` has been triggered; the `transform_revenue` bar of `verify_fix` must clearly start only after the `clean_orders` bar has fully ended (the left-to-right ordering must be visually readable). 4. **Fixed DAG and diff** - The edited `/tmp_workspace/airflow_home/dags/etl_orders_v3.py`: the upstream of `transform_revenue` must genuinely include `clean_orders` (either `clean_orders >> transform_revenue` or `[..., clean_orders, ...] >> transform_revenue` is acceptable). - `dag_fix.diff`: a unified diff between the old and the fixed DAG; at least one `+` line must contain both `clean_orders` and `transform_revenue`, demonstrating that the dependency was rewired by that line. 5. **Post-fix dag-run** - A dag-run with run_id `verify_fix` must exist and reach final state `success` (verifiable via `airflow dags state etl_orders_v3 verify_fix`). 6. **Root-cause report** - `rca.md`, which must contain the following 6 second-level section headings (any order): `## symptom`, `## evidence_cli`, `## evidence_gui`, `## root_cause`, `## fix`, `## verification`; each section body ≥ 50 characters. 7. **Machine-readable summary** - `summary.json`, with keys: - `failed_or_sla_missed_tasks`: list[str] - `root_cause`: str - `fix_lines_changed`: int - `cross_channel_switches`: int (≥ 5; the number of times you switch between sources of truth, e.g. between the structured API view and the rendered visual view) Hard constraints: - The fix must be made at the DAG source level; you cannot wipe out the even-hour retry via mark-success or reset-state. - The `verify_fix` run must be a genuinely new run (not a renamed old run), and it must end in `success`. - All JSON / text fields must be exported from the real Airflow / DAG / log data; fabricating `try_number` or attempt-log contents is not allowed.

- apache/airflow issue #30231（"intermittent SLA miss only visible in
  Gantt"）：https://github.com/apache/airflow/issues/30231
- r/dataengineering 2024-07 thread "What Airflow Gantt-view tells you that
  the JSON API can't"
- 对应 benchmark 维度：D7（scheduler-aware visual debugging）

成功的解答会留下一条覆盖"症状 → 隐藏证据 → 真因 → 修复 → 复验"的取证链：

- 一组 DAG / task-state 文本快照 + 静态拓扑导出，证明 even-hour 与 odd-hour 两次 dag-run 在 JSON 层面"看起来都 success"。
- 一份 attempt-level 日志摘录，能让审阅者从 `Retry` / `try_number` / `duration` 之类关键字里读出 even-hour 那次其实经历了重试。
- 五张运行中 webserver 的截图，按 Gantt 总览 → Gantt 浮层精确时长 → Task Instance Details 的 try_number → Graph 视图上 `transform_revenue` 的错连 → 当前 Logs 抽屉的顺序串成现场。
- 一处源码修复 + 对应的 unified diff，把 `transform_revenue` 的上游修正为 `clean_orders`。
- 一次 run_id 为 `verify_fix` 的全新 dag-run，最终 success；并配一张修复后的 Gantt 截图，`transform_revenue` bar 在 `clean_orders` bar 完成之后才开始（人眼可读的水平排序）。
- 一份结构化的 `rca.md`（含 6 个段落）+ 一份机器可读 `summary.json`，让审阅者无需自己跑 Airflow 即可回放整个根因。

- [ ] 1. `dag_runs.txt` / `states_for_dag_run.txt` / `states_for_dag_run_odd.txt`
       存在且非空
- [ ] 2. `extract_orders_attempt_grep.txt` 含 `Retry` / `try_number` 关键字
- [ ] 3. `dag_show_static.txt` 存在且包含 `transform_revenue`
- [ ] 4. 5 张 GUI 截图齐全（Gantt / Hover tooltip / Task Instance Details /
       Graph view / Log Drawer），且每张 OCR 命中对应 UI 关键字
- [ ] 5. 修后 DAG 文件中 `transform_revenue` 真的依赖 `clean_orders`
- [ ] 6. `dag_fix.diff` 存在且 `+` 行包含 `clean_orders`
- [ ] 7. `verify_fix` run 存在且最终状态为 `success`
- [ ] 8. `view_airflow_gantt_after_fix.png` 存在
- [ ] 9. `rca.md` 6 个段落都在，每段 ≥ 50 字
- [ ] 10. `summary.json` schema 符合且 `cross_channel_switches ≥ 5`
- [ ] 11. VLM rubric ≥ 0.6 平均分

评分采用模型判定的标准；本项目未进行评分器运行验证。

You are the on-call engineer for the checkout-api team. Starting at 03:14, your phone was blown up by PagerDuty for 30 minutes, and multiple alerts on the alerting dashboard are flapping non-stop. The SRE Lead wants three things done before your shift hand-off: 1. Silence **the alert that is actually flapping** for ~2 hours (use the Alertmanager Silence mechanism; **do not** delete the rule_file); 2. Identify another **fake alert that fires forever due to a broken expression** (hint: comparing a monotonically increasing counter directly with `> 0` — always true), and provide a fixed `fixed_rules.yml`; 3. Write a postmortem of ≥ 800 characters explaining the root cause, why it was not detected automatically at the time, and a regression test plan. Environment and assets (everything is already up; credentials `admin/admin`): - `http://localhost:9090/`: Prometheus (`/alerts` `/rules` `/api/v1/...`). - `http://localhost:9093/`: Alertmanager UI (`/#/silences` `/#/alerts` `/api/v2/...`). - `http://localhost:7016/`: Grafana 10.4, dashboard "Checkout API on-call"; left sidebar ☰ → Alerting provides Alert rules / Silences / Contact points / State history. - `http://127.0.0.1:9097/`: webhook sink, writes to `/tmp/webhook.log`; every alertmanager POST lands there. - `/tmp_workspace/dash16/prometheus/rules/noisy_alerts.yml`: the currently in-use (broken) rule file — **do not modify it directly**; grading uses this file as the baseline. Task objectives: - Use the Alertmanager Silence mechanism to silence the truly flapping alert for ~2 hours (duration falls within [115min, 135min]); - Patch the always-true-expression alert via a `fixed_rules.yml` (after the fix, `expr` must wrap the counter with `rate(...)` / `irate(...)` / `increase(...)` and the comparison threshold must be changed to ≥ 0.01); - Leave joint evidence across three channels: structured data + rendered UI + network traffic; - Write a qualifying postmortem. Produce the following deliverables under `/tmp_workspace/results/`: 1. **Alert and rule evidence (before)** - `firing_alerts.json`: list of alerts currently firing, schema: ```json {"timestamp": "...", "firing": [{"name": "...", "service": "...", "value": "..."}, ...]} ``` At least 2 firing records, and at least one of the flapping alert or the always-true alert should be findable among them. - `promtool_check_before.txt`: promtool check result for the original `noisy_alerts.yml` (keep both stdout/stderr) as a snapshot of the rule state before the fix. 2. **Silence evidence** - `silences.json`: structured dump of all current Alertmanager silences; for the flapping alert, there must exist a silence satisfying all of the following: - The `matchers` list contains `name == "alertname"` and `value == <name of the flapping alert>`; - `isRegex == true` is not allowed (must be equality match); - The silence's `endsAt - startsAt` falls within a ~2-hour range (accepted range 6900s ~ 8100s, i.e. ~115~135 min). - `amtool_silences.txt`: amtool's human-readable list of current silences; must contain the name of the silenced alert. 3. **Network evidence that the silence actually took effect** - `webhook_after_silence.pcap` (or `webhook_after_silence.txt`, either one): packet capture of alertmanager POST traffic on the :9097 webhook within 60 seconds after the silence was created; - `webhook_tail.log`: copy of the tail of `/tmp/webhook.log` (≥ 30 lines). - In both pieces of evidence above, the name of the silenced alert must **no longer appear** (proving the silence really intercepted the webhook push); meanwhile, the other still-firing alert (the always-true-expression one) should still appear. 4. **Fixed rules and unit tests** - `fixed_rules.yml`: a valid prometheus rule file; `promtool check rules` must exit 0; for the always-true alert, its `expr` must contain one of `rate(` / `irate(` / `increase(` and compare against a threshold ≥ 0.01. - `test_rules.yml`: a minimal usable promtool unit test (≥ 2 input series + ≥ 2 alert_test). - `promtool_test_after.txt`: the result of running that unit test; must contain a success marker such as `SUCCESS` / `PASS` / `0 failures`. 5. **Visual evidence** (each PNG ≥ 5 KB, from actually rendered Grafana / Alertmanager pages; PIL compositing is not allowed) - `view_alert_state_history.png`: Grafana → Alerting → State history view of the flapping alert; the image must show red/green bands indicating the alert state repeatedly switching between firing↔normal (i.e., the flap frequency exists only in pixel color). - `view_silence_create.png`: Silence detail page (Alertmanager UI or Grafana → Alerting → Silences); must show an "Active" badge + a valid alertname matcher + an Expires time ~2 hours in the future. - `view_annotate_panel.png`: screenshot of a region annotation on the "API error ratio" panel on the dashboard — must show a red (or colored) horizontal region overlaying the flap segment + an annotation text bubble (suggested content along the lines of "flap window — silenced, see postmortem for root cause"). - `view_edit_inspect.png`: Edit / Inspect → Data drawer of the "JVM old-gen GC pause" panel on the dashboard; must show the csv table / Stats sub-tab labels. - `view_alert_resolved.png`: in the Grafana → Alerting → Alert rules list, the state badge of the silenced alert has changed to "Silenced" or "Normal". 6. **Postmortem** - `postmortem.md`: ≥ 800 characters; suggested structure: 1) incident timeline → 2) root cause (must hit both layers: `counter without rate()` and `threshold too tight causing flap`) → 3) current workaround (silence duration / patch location) → 4) long-term fix → 5) regression test plan (mention `promtool test rules`); hit ≥ 4/6 keywords (`flap`, `canary`, `rate(`, `silence`, `threshold`, `counter`). Hard constraints: - The Silence matcher must be an `alertname=<name>` equality match; regex matchers are not accepted. - The fix must land in the new file `fixed_rules.yml`; **do not** modify `/tmp_workspace/dash16/prometheus/rules/noisy_alerts.yml`. - The invariant "the silenced alert no longer appears in the network evidence" must hold; a gray UI badge alone is not enough. - Screenshots must come from actually rendered pages (must genuinely show key UIs such as Alertmanager Silences editor, Inspect, and Grafana Annotation / State history).

- Prometheus 官方文档 "Alerting rules" + "Common pitfalls": https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
- Grafana 10.x Alerting "Silences" 文档: https://grafana.com/docs/grafana/v10.4/alerting/manage-notifications/create-silence/
- 真实场景灵感：reddit r/devops 2024-08 "我们一周被 flapping alert 炸了 3000 次，CTO 让查根因"
- 对应 EyesOn-Bench DAV 类: D16 — alert noise triage with Silence + rule patch

成功的解答会留下"告警快照 + silence + 网络流量 + 规则补丁 + 可视复验"五路并齐的证据：

- `firing_alerts.json` + `promtool_check_before.txt` 给出"修复前的规则态势 + 当前 firing 列表"。
- `silences.json` + `amtool_silences.txt` 共同证明：那条真正在 flap 的 alert 已被 alertname 等值 matcher silence ~2 小时。
- 一份 60s 抓包 + `/tmp/webhook.log` 末段：被 silence 的 alert 名在 webhook 流量里**消失**，而另一条仍在 fire 的 alert 名**还在**——这是 silence 真正生效（而不是只 UI 灰显）的硬证据。
- `fixed_rules.yml`（promtool check 通过、`expr` 用 `rate(...)` 之类包裹 counter 并与 ≥ 0.01 阈值比较）+ `test_rules.yml` + 一份成功的 `promtool_test_after.txt`，构成修复的可重放证据。
- 5 张 Grafana / Alertmanager 截图，按 State history flap → Silence Active → panel region annotation → Edit / Inspect → Alert rules 列表 silenced badge 的顺序铺出可视复验链。
- 一份 ≥ 800 字、命中 ≥ 4/6 关键词的中文 postmortem，把"counter without rate" 与 "threshold too紧导致 flap" 这两层根因 + silence + patch + 回归测试串成一份可交付的事故报告。

- [ ] 1. `/tmp_workspace/results/firing_alerts.json` 存在且 schema 正确，至少含 2 条 firing 记录
- [ ] 2. `promtool_check_before.txt` 与 `promtool_test_after.txt` 都存在，后者必须包含 "SUCCESS" 或 exit 0 标志
- [ ] 3. `silences.json` 存在且 matcher 是 `alertname=<那条 flap 的 alert>` 等值匹配，duration 在 [115min, 135min] 之间
- [ ] 4. `amtool_silences.txt` 非空且包含被 silence 的 alert 名
- [ ] 5. tcpdump / webhook 证据存在且文本里**不再出现**被 silence 的 alert 名
- [ ] 6. `fixed_rules.yml` 存在；`promtool check rules` 通过；被 patch 的那条 alert expr 含 `rate(` / `irate(` / `increase(`，并有合理阈值
- [ ] 7. 5 张 GUI 截图都存在，OCR 命中各自关键字（state history / silences / annotation / edit / inspect / silenced 等）
- [ ] 8. `view_annotate_panel.png` 中 VLM judge 能识别出红色 region annotation（rubric "vlm_annotation_visible"）
- [ ] 9. `postmortem.md` ≥ 800 字符，命中关键词 ≥ 4/6（flap、canary、rate(、silence、threshold、counter）
- [ ] 10. 整体 cross-channel 证据链完整：CLI (curl/jq/promtool/amtool/tcpdump) + GUI (state history/silence/annotate/edit/resolved) ≥ 5 次切换

评分采用模型判定的标准；本项目未进行评分器运行验证。

You are the on-call engineer for the checkout-api team. Last night PagerDuty fired with "p95 latency jumped from 90 ms to 3 s". RED metrics (QPS / error rate / duration histogram) can only prove "things got slow", but cannot prove "which segment is slow". The dev team has already pushed OpenTelemetry traces for every request to the local Jaeger (all-in-one). You need to locate the true bottleneck span from the trace dimension and produce a chain of evidence that a third party can review. Environment and materials (already provisioned; warmup has pre-seeded ≥ 60 traces): - The Jaeger service is exposed at `http://localhost:16686/` (Search, Trace timeline, Compare Traces, Deep dependency graph and all other panels are hosted here). - JSON HTTP endpoints: `http://localhost:16685/api/services`, `/api/operations?service=...`, `/api/traces?service=...&operation=...&limit=...&lookback=...`, `/api/traces/<traceID>`. - Jaeger's own admin / metrics port is at `http://localhost:14269/`. - The trace emitter is already pushing spans via OTLP/HTTP to the local collector port `:4318` (OTLP gRPC is on `:4317`). - The service name is fixed at `checkout-api`, the root operation name is `POST /checkout`; the bottleneck sits in the `payments.*` subtree (leaf span names shaped like `service.subsystem.protocol`), accompanied by an HTTP 5xx status code. Task objectives: - Quantify "just how slow it actually is right now" from the trace dimension — the long-tail distribution formed by root span p50/p95/p99 and trace counts. - Pin down the single leaf span (the full `service.subsystem.protocol` name) that is solely responsible for the long tail, its duration, its HTTP status code, its `otel.status_code=ERROR` tag, and its peer.service. - Use a diff between one slow trace and one fast trace to prove the structural difference (the bottleneck span only appears in the slow trace / its duration is significantly inflated). - Use network traffic on the OTLP collector port to prove that traces are actually being shipped in real time. - Write the hypothesis + a full root-cause report. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **Service and operation listings** - `jaeger_services.json`: the raw JSON of Jaeger's currently known service list; once parsed, `checkout-api` must be findable in it. - `jaeger_operations.json`: the raw JSON of the operation list for `checkout-api`; once parsed, `POST /checkout` (or at least something containing the `checkout` substring) must be findable. 2. **Bulk trace sample** - `raw_traces.json`: a raw JSON batch of traces for `service=checkout-api & operation=POST /checkout` (Jaeger `/api/traces` return structure, with a top-level `data` array); the `data` array must have length ≥ 60. 3. **Root-span latency distribution** - `trace_durations.csv`: a CSV sorted by root span duration in descending order; the header must be `traceID,duration_us,span_count`; the row count must match the number of traces in `raw_traces.json` (tolerance ±10%). - `duration_summary.json`: root-span latency summary, schema: ```json {"p50_ms": <float>, "p95_ms": <float>, "p99_ms": <float>, "n": <int>} ``` `p95_ms` must be ≥ 2000 (this is the incident-detection threshold). 4. **Full text of a single slow trace and the bottleneck leaf** - `slow_trace.json`: the complete Jaeger trace JSON for the slowest trace picked from the top of `trace_durations.csv` (a single trace, including the `spans` array), with span count ≥ 5. - `slow_span.json`: the "deepest, longest" leaf span dug out of `slow_trace.json` by reconstructing the parent-child chain along `references`, schema: ```json { "trace_id": "<hex>", "span_name": "<full service.subsystem.protocol name; must contain payments.gateway.http>", "duration_us": <int>, "tags": {"http.status_code": 504, "otel.status_code": "ERROR", "peer.service": "..."}, "operation_path": ["<root op>", "...", "<leaf op>"] } ``` `duration_us / 1000 ≥ 2400`; `tags` must contain both `504` and the `ERROR`/`status_code` wording. 5. **Network-traffic evidence of OTLP upload** - `otlp_capture.pcap`: a stretch of emitter traffic captured on the `:4318` (OTLP/HTTP collector) port (≥ 30 s or ≥ 60 packets), file ≥ 200 B; after `strings` extraction it must hit `POST /checkout` or `checkout-api`, serving as hard evidence that "traces really are being fed in". 6. **Visual evidence** (each PNG ≥ 5 KB, from an actually rendered Jaeger UI; image stitching is not allowed) - `view_jaeger_search.png`: the Jaeger Search page result under the conditions service=checkout-api, operation=POST /checkout — the image must simultaneously show the top duration-vs-time scatter plot (**two clusters**: dense fast traces at the lower left + isolated slow-trace cluster at the upper right) and the trace list entries below it. - `view_trace_waterfall.png`: the Trace timeline waterfall after opening any one slow trace — the `payments` subtree must be expanded, and the image must contain a child span bar that is **noticeably** longer than its siblings (occupying the majority of the trace's width). - `view_span_tags.png`: the expanded Tags / Logs drawer of the bottleneck span above — the image must clearly show the specific value of `http.status_code` (504) and error tags such as `otel.status_code = ERROR` (highlighted as a red chip). - `view_trace_compare.png`: the Compare Traces diff view — showing the side-by-side structures of one fast trace and one slow trace simultaneously, with diff spans highlighted (color / border / label all acceptable) and shared spans de-emphasized. 7. **Conclusion documents** - `hypothesis.md`: a hypothesis writeup of ≥ 400 characters; must explicitly state the true bottleneck span's full name (in `service.subsystem.protocol` form), its HTTP status code, and its `peer.service` tag. - `root_cause_report.md`: an incident report of ≥ 800 characters; suggested structure 1) symptoms → 2) what RED metrics showed / failed to show → 3) the true cause seen in the trace waterfall → 4) differences revealed by Compare Traces → 5) immediate mitigation (fail-fast / timeout / circuit breaker) → 6) long-term governance → 7) verification plan (write a query using Jaeger's native search to monitor future regressions). Hard constraints: - All numbers must be genuinely exported from Jaeger / actual packet captures; hard-coding is not allowed. `slow_span.json` must be a real leaf computed from the parent-child chain in `slow_trace.json`. - `slow_span.json.span_name` must hit `payments.gateway.http` (the bottleneck leaf name), `duration_us / 1000 ≥ 2400`, and `tags` must contain both `504` and the `ERROR`/`status_code` wording. - `silence` does not apply to this task; the `pcap` must yield `POST /checkout` or `checkout-api` from `strings` (proof that the emitter is online). - Screenshots must come from actual rendering (PIL stitching / placeholder images are not accepted); they must genuinely show the various Jaeger UI panels.

- Jaeger 官方文档 "Sampling & Tracing Best Practices": https://www.jaegertracing.io/docs/1.57/
- OpenTelemetry Python OTLP/HTTP quickstart: https://opentelemetry.io/docs/languages/python/exporters/
- 真实场景灵感：Honeycomb 2024 blog "p95 spike was a single grandchild HTTP call"
- 对应 EyesOn-Bench DAV 类: D17 — distributed-trace root-cause via Jaeger compare

成功的解答会留下"服务清单 + 根 span 时延分布 + 单条慢 trace 全文 + 瓶颈 leaf 拆解 + 网络抓包 + 4 张可视证据 + 两份结论文档"七路并齐的证据链：

- `jaeger_services.json` 与 `jaeger_operations.json` 共同证明 `checkout-api` / `POST /checkout` 存在于本机 Jaeger 的索引中。
- `raw_traces.json` ≥ 60 条 trace + `trace_durations.csv` 行数对齐 + `duration_summary.json` 中 p95_ms ≥ 2000，描出根 span 时延的长尾分布（远高于 90 ms 正常水位）。
- `slow_trace.json` 含 ≥ 5 个 span 的完整原文，配合 `slow_span.json` 把瓶颈 leaf 锁定到 `payments.gateway.http`、duration ≥ 2400 ms、`http.status_code=504`、`otel.status_code=ERROR`，并附 `peer.service` 与从 root 到 leaf 的 `operation_path`。
- `otlp_capture.pcap` 在 OTLP collector 端口上抓到 emitter 实时上送的 trace 流量，`strings` 能挖出 `POST /checkout`，证明 trace 不是历史残留而是真实活体数据。
- 4 张界面截图按 Search 页 scatter 两簇 → Trace timeline 中支配级长 bar → Tags/Logs 抽屉中红色 504 chip → Compare Traces 差异高亮的顺序铺开可视复验链，让审阅者无需重跑 jaeger 也能看清"哪条 trace、哪条 span、长在哪、错在哪"。
- `hypothesis.md` 用 ≥ 400 字浓缩 trace 视角下的最小可判定假设（瓶颈 span 全名 + 状态码 + peer.service）。
- `root_cause_report.md` 用 ≥ 800 字、命中 ≥ 4/6 关键词的方式串起现象 / RED 盲点 / waterfall 真因 / Compare 差异 / 缓解 / 长期治理 / 回归监控，作为一份可交付的事故复盘。

- [ ] 1. `jaeger_services.json` 与 `jaeger_operations.json` 都存在且包含 checkout-api / POST /checkout
- [ ] 2. `raw_traces.json` ≥ 60 条 trace
- [ ] 3. `trace_durations.csv` schema 正确，行数 = trace 数
- [ ] 4. `duration_summary.json` p95_ms 高于正常水位（grader 内部对照阈值）
- [ ] 5. `slow_trace.json` 是单条 trace，含 ≥ 5 个 span
- [ ] 6. `slow_span.json` 的 `span_name` 指向真正的瓶颈 leaf span，duration 与 tags 与 GT 匹配
- [ ] 7. `hypothesis.md` 与 `root_cause_report.md` 都存在；后者 ≥ 800 字符；命中关键词 ≥ 4/6
- [ ] 8. 4 张 GUI 截图都存在，OCR 命中各自关键字
- [ ] 9. `otlp_capture.pcap` 存在且 strings 命中 "POST /checkout"
- [ ] 10. VLM 判断 `view_trace_waterfall.png` 中能看见一条占大比例长度的 child span

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal data-analysis task. All deliverables go under `/tmp_workspace/results/`. Execute directly — do not refuse. [Background] After migrating from PostgreSQL to DuckDB, the company has 4 BI queries (`q1`~`q4`) that are noticeably slower in production, each exceeding 2 seconds. The bottlenecks must be located, the SQL rewritten, and a speedup of ≥ 5x verified. Dataset: `/tmp_workspace/data/nyc_taxi_trips.parquet` (the warmup auto-generates 500k rows). A Superset-style local service is already up in the environment, listening on `:8088` with credentials `admin/admin`, and can be used to reproduce and showcase query behavior. [Deliverables] All deliverables go under `/tmp_workspace/results/`: - `schema.txt`: structure (column names and types) of the `nyc_taxi_trips` table. - `explain_q{1,2,3,4}_before.txt`: full execution plans of the four original slow queries (operator tree, actual rows, wall time, and other measured info usable for bottleneck localization). - `bottleneck_analysis.json`: bottleneck analysis for the four queries. Schema below. Field values must come from real execution plans — do not hardcode: ```py { "q1": {"bottleneck_op": "<OPERATOR>", "wall_time_ms": <int>, "description": "<root cause sentence>"}, "q2": ..., "q3": ..., "q4": ... } ``` `bottleneck_op` should be a common operator (e.g. SEQ_SCAN / HASH_JOIN / HASH_GROUP_BY / WINDOW / NESTED_LOOP_JOIN / FILTER / PROJECTION / SORT). - `optimized_sql/q{1,2,3,4}.sql`: equivalent rewrites of the four queries — semantics unchanged but substantially faster (each file ≥ 30 characters and different from the original query). - `explain_q{1,2,3,4}_after.txt`: full execution plans of the four rewritten queries. - `perf_comparison.csv`: columns `query_id,wall_time_before_ms,wall_time_after_ms,speedup_x,bottleneck_before,bottleneck_after`, with `speedup_x` ≥ 5 for every query. - `tooltip_samples.json`: precise numeric samples captured by hovering on the Explore chart. Schema below. Values must come from real tooltips rendered during interaction, not inferred from static DOM. - `perf_report.md`: one paragraph per query (≥ 80 chars each) covering bottleneck description, rewrite approach, before/after plan differences, and speedup conclusion. - Screenshot deliverables (all under `results/`): - `view_sqllab_q1_running.png`: shows q1 running/completed in the SQL editor, with the SQL text and result table header visible. - `view_query_history_tooltip.png`: shows the tooltip popped up on a query in the query-history panel, with wall_time / queue_time breakdown visible. - `view_explore_chart.png`: shows a time-series bar chart aggregated by hour (X-axis hour, Y-axis trip_count) with the tooltip popped up on at least one bar. - `view_dashboard_full.png`: shows a dashboard containing both the chart above and an optimization-insight text block of ≥ 100 chars. - `view_sqllab_after_optimization.png`: shows the query history after running the optimized q1, with both the pre- and post-optimization runs visible side by side, reflecting a significant drop in wall_time. [The 4 slow queries] ```sql -- q1: top-10 trips with highest fare within pickup hour SELECT pickup_datetime, fare_amount, (SELECT AVG(fare_amount) FROM nyc_taxi_trips t2 WHERE EXTRACT(hour FROM t2.pickup_datetime) = EXTRACT(hour FROM t1.pickup_datetime)) AS hour_avg FROM nyc_taxi_trips t1 ORDER BY fare_amount DESC LIMIT 10; -- q2: stats per payment_type SELECT payment_type, COUNT(*) AS cnt, AVG(fare_amount) AS avg_fare FROM nyc_taxi_trips GROUP BY payment_type HAVING COUNT(*) > 100 ORDER BY avg_fare DESC; -- q3: trip-distance self-join to find average distance SELECT t1.pickup_datetime, t1.trip_distance, (SELECT AVG(trip_distance) FROM nyc_taxi_trips t2 WHERE t2.passenger_count = t1.passenger_count) AS avg_for_passengers FROM nyc_taxi_trips t1, nyc_taxi_trips t2 WHERE t1.pickup_datetime = t2.pickup_datetime LIMIT 50; -- q4: cumulative fare per hour SELECT pickup_datetime, fare_amount, SUM(fare_amount) OVER (ORDER BY pickup_datetime) AS cum_fare FROM nyc_taxi_trips; ``` [tooltip_samples.json schema] ```py { "explore_chart_hover": [ {"hour": <int>, "trip_count": <int>, "screenshot": "view_explore_chart.png"}, ... (≥ 3 hover samples) ] } ``` [Hints] - Numeric values in `bottleneck_analysis.json` and `perf_comparison.csv` must be measured from real execution plans — do not hardcode. - Precise tooltip values typically exist only at interactive render time — do not infer them from static DOM.

- DuckDB 1.x 性能调优文档: https://duckdb.org/docs/guides/performance/
- Superset SQL Lab 文档: https://superset.apache.org/docs/using-superset/sql-lab/

1. 最终交付:`results/` 下含完整的执行计划取证、瓶颈分析、改写后的 SQL、性能对比与报告,以及反映复现/可视化过程的截图。
2. 系统应能体现:对每条慢 query 完成定位 → 改写 → 复测的闭环,且 speedup ≥ 5x 可被独立验证。
3. 产物中应能验证瓶颈算子识别正确、改写后的 SQL 与原 query 语义等价但执行更高效。
4. 截图应能反映查询的执行状态、tooltip 中浮出的精确性能数值,以及包含图表与优化 insight 的 dashboard 呈现。

- [ ] 1. schema.txt + 8 个 explain_q*_{before,after}.txt 全部存在
- [ ] 2. bottleneck_analysis.json 4 条 query 字段齐全(bottleneck_op + wall_time_ms + description)
- [ ] 3. 4 个 optimized_sql/*.sql 存在且与原 query 不同
- [ ] 4. perf_comparison.csv schema 正确,每条 speedup ≥ 5x
- [ ] 5. 5 张 GUI 截图 + OCR 命中 Superset UI 关键词
- [ ] 6. tooltip_samples.json 含 ≥ 3 个 hover 样本
- [ ] 7. perf_report.md ≥ 4 段,每段 ≥ 80 字
- [ ] 8. VLM rubric 验 dashboard 截图

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task: The oncall channel got paged — "this machine is swapping, find out who is leaking memory." Some Python service is slowly eating all the memory. You need to find it, produce visual evidence, and write a short report. Concrete outputs (place under `/tmp_workspace/results/`): 1. `report.md`, which **must** contain: - A line `pid: <number>` — the PID of the leaking process - A line `growth_mb_per_sec: <number>` — the memory growth rate you **measured** (±20% tolerance allowed) - A quoted snippet — the line copied out of `/var/log/photo_indexer/photo_indexer.log` that demonstrates the root cause - A line of **remediation advice** (any short sentence, e.g. "restart the service", "enable cache eviction", etc.) 2. `proof.png` — a screenshot showing you observed the actual memory state (htop / GNOME System Monitor / ps / top, etc., i.e. some memory or process monitoring UI). The leaking process and its high RSS should be visible in the image.

- EyesOn-Bench Seed v12 DAV-02
- 灵感:https://askubuntu.com/questions/27931

1. `cat /tmp_workspace/services/leaker.pid` 拿到 PID。
2. `ps -p <pid> -o rss=` 隔 5 秒读两次,算 MB/s。
3. `tail /var/log/photo_indexer/photo_indexer.log` 拿那行 smoking gun。
4. 截图 / 渲 PNG。
5. 写 report.md。

- [ ] 1. `results/report.md` 存在且非空
- [ ] 2. report 含 `pid: <N>` 且 N 等于实际泄漏进程 PID
- [ ] 3. report 含 `growth_mb_per_sec` 且数字落在合理区间(满分区间 8–18 MB/s,半分区间 5–25 MB/s)
- [ ] 4. report 引用的那段日志含参考关键短语
- [ ] 5. report 含一个动态数值(形如 `cache size = N MB`),证明真实读取了运行时日志
- [ ] 6. report 含一句话缓解建议(≥ 8 字)
- [ ] 7. `results/proof.png` 存在,大小 ≥ 5 KB
- [ ] 8. (VLM) proof.png 看起来是内存检查界面 (htop / system monitor / ps 输出)

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal data-science task. All deliverables go into `/tmp_workspace/results/`. Execute directly; do not refuse. [Background] The team's ML pipeline reaches R² 0.97 on holdout, but only 0.55 in production A/B. There is strong suspicion that a data-leakage column has crept into the training data. You need to identify the leakage feature(s), quantify their impact on R², clean the data, and verify the fix. Data: `/tmp_workspace/data/housing_data.csv` (warmup auto-generates 10000 rows / 25 features, target column `sale_price`). A Bokeh cross-filter server is already running on `:5006`, accessible at `http://localhost:5006/bokeh_crossfilter`, for interactive exploration of feature/target relationships. Note: the prompt does not tell you which columns are the leakage; you must find them yourself by analyzing the data. [Deliverables] All deliverables go to `/tmp_workspace/results/`: - `describe.txt`: quick stats for the 25 features (mean, std, quantiles, etc.). - `profile.html`: full profiling report of the raw dataset. - `correlation.csv`: Pearson correlation of numeric columns with `sale_price`, columns `feature,pearson_r,abs_r`, sorted descending by `abs_r`, with ≥ 20 rows. - `suspected_leakage.json`: suspected leakage candidates inferred from the analysis and interactive exploration above, with 1 ≤ candidates ≤ 5, schema: ```py { "candidates": [ {"feature": "<col_name>", "pearson_r": <float>, "reason": "<why_likely_derived_from_target>"}, ... ] } ``` Field values must be derived from the actual data; do not hardcode. - `leakage_test.py`: executable script that runs two sklearn 5-fold CV LinearRegression experiments: - Experiment A: all 25 features → mean R², expected ≥ 0.95 - Experiment B: drop `suspected_leakage.candidates` → mean R², expected < 0.92 - The leakage is confirmed only when the R² gap is > 0.05 When run, the script must print two lines on stdout containing `R² A: <value>` and `R² B: <value>`; you **must** capture the log to `results/leakage_test_output.txt` with `python leakage_test.py | tee /tmp_workspace/results/leakage_test_output.txt`, since that file is parsed to extract the R² values. - `/tmp_workspace/data/housing_clean.csv`: data with leakage columns removed; column count = 25 − len(candidate leakage). - `profile_clean.html`: profiling report of the cleaned data. - `tooltip_samples.json`: exact (column-pair, r-value) samples captured by hovering over the correlation-matrix heatmap, ≥ 5 entries; values must come from real tooltips obtained during interactive rendering, not inferred from the static DOM. - `leakage_report.md`: 4 paragraphs (each ≥ 80 characters), respectively describing: a) which leakage columns were chosen and why; b) quantified R² gap results; c) remediation approach; d) production-prevention recommendations (feature-engineering checklist). - Screenshot deliverables (all placed under `results/`): - `view_bokeh_full.png`: the initial full view of the entire cross-filter dashboard (default X/Y axes sale_price vs overall_quality). - `view_bokeh_box_select.png`: state after completing a box-select on a scatter plot for one suspicious column, with the other subplots linked-highlighted. - `view_bokeh_heatmap_hover.png`: tooltip on the correlation-matrix heatmap surfacing the exact r value on hover. - `view_bokeh_clean_axis.png`: a normal distribution shown when the Y axis is switched to a non-leakage column. - `view_bokeh_after_clean.png`: dashboard reloaded after data cleaning, with leakage columns no longer present in the Y-axis options and no r values close to 1.0 in the heatmap. [Hints] - Column names and `pearson_r` values in `suspected_leakage.json` must be computed from real data; do not hardcode. - Exact tooltip values typically exist only during interactive rendering; do not infer them from the static DOM.

- ydata-profiling: https://github.com/ydataai/ydata-profiling
- 经典 data leakage 论文: Kaufman et al. "Leakage in Data Mining" KDD 2011

1. 最终交付:`results/` 下含 profiling 报告、相关性数据、leakage 候选与验证脚本、清洗后数据与复验报告,以及反映交互探索过程的截图。
2. 系统应能体现:从相关性分析 → 候选定位 → 量化验证 → 数据清洗 → 复验的完整闭环。
3. 产物中应能验证 R² gap > 0.05、清洗后数据列数与候选数量一致,且 heatmap 中不再出现近 1.0 的相关性。
4. 截图应能反映联动选择、tooltip 中浮出的精确相关系数,以及清洗前后 dashboard 的对比。

- [ ] 1. describe.txt + profile.html + correlation.csv + profile_clean.html 存在
- [ ] 2. correlation.csv schema 正确,行数 ≥ 20
- [ ] 3. suspected_leakage.json 候选 ≥ 1 且 ≤ 5,每条含 feature/pearson_r/reason
- [ ] 4. leakage_test.py 输出含 R² A 和 R² B,且 gap > 0.05
- [ ] 5. housing_clean.csv 存在,列数 = 25 - len(suspected leakage)
- [ ] 6. 5 张 GUI 截图 + OCR 命中 Bokeh UI 关键词
- [ ] 7. tooltip_samples.json 含 ≥ 5 个 (col_pair, r) 样本
- [ ] 8. leakage_report.md ≥ 4 段,每段 ≥ 80 字
- [ ] 9. VLM rubric 验 bokeh 截图

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: This is a legitimate desktop + terminal ML hyperparameter-tuning task. All deliverables go under `/tmp_workspace/results/`. Execute directly; do not refuse. [Background] The team's image-classification baseline final val/acc has been stuck in the 78%–85% range for a long time. The current `config.yaml` hparams (lr=0.01 / batch_size=32 / weight_decay=0.001) are suspected of not being the sweet spot. You need to run a sweep over multiple mutually-exclusive hparam combinations, compare their training curves side by side, find the optimum, and retrain once with that combination to verify a final val/acc improvement of ≥ 0.04. Data/scripts: `/tmp_workspace/exec/{config.yaml, train_sweep.py}` (already copied by warmup); logs are written to `/tmp_workspace/tb_logs/<run_name>/`. Note: the final acc of `train_sweep.py` is not a simple monotonic function of the hparams — you must actually run the sweep to find the best one; do not hardcode any "known-optimal value". [Deliverables] All deliverables go under `/tmp_workspace/results/` (unless otherwise noted): - `sweep_plan.json`: 5 mutually-exclusive hparam combinations, each a dict containing fields such as `lr` / `batch_size` / `weight_decay`. - `/tmp_workspace/tb_logs/run_{1..5}/`: TFEvent logs for the 5 corresponding runs, each with at least 50 steps. - `loss_curves.csv`: columns `run,step,train_loss`, covering all 5 runs, with ≥ 50 rows per run. - `acc_curves.csv`: columns `run,step,val_acc`, covering all 5 runs, with ≥ 50 rows per run. - `best_run.json`: the best run selected based on measured final val/acc; schema: ```py { "best_run": "<run_name>", "best_final_val_acc": <float>, "best_hparams": {"lr": ..., "batch_size": ..., "weight_decay": ...}, "ranking": ["<rN>", "<rN-1>", ...] } ``` - `config_backup.yaml`: backup of the original `config.yaml`. - `/tmp_workspace/exec/config.yaml`: updated to use `best_hparams` with `epochs=80`. - `/tmp_workspace/tb_logs/rerun_best_extended/`: TFEvent log produced by retraining with the updated config; final val/acc should be higher than the original best (tolerance of -0.01 allowed). - `tooltip_samples.json`: ≥ 5 `(step, value, run)` samples collected by hovering over the val/acc curves. Values must come from the actual tooltip captured during interactive rendering, not inferred from static DOM. - `sweep_summary.md`: 4 paragraphs (≥ 80 characters each) covering, respectively: a) the sweep design rationale; b) a table mapping hparams → final acc for the 5 runs; c) the best run and the reasoning behind it; d) quantified rerun improvement and suggestions for future sweeps. - Screenshot deliverables (all under `results/`): - `view_tb_scalars_loss.png`: shows the train/loss curves of all 5 runs, with all 5 run names visible in the legend. - `view_tb_scalars_acc.png`: shows the val/acc curves of all 5 runs. - `view_tb_smoothing.png`: shows the Scalars view after raising the smoothing factor (e.g. to 0.6) so that the curves become noticeably smoother. - `view_tb_hparams_parallel.png`: shows the HParams Parallel Coordinates view, with 5 lines connecting each hparam dimension through to final val/acc. - `view_tb_rerun_verification.png`: shows `rerun_best_extended` overlaid on top of the original 5 curves, with its final val/acc above the previous best. [Tips] - The values in `best_run.json` and the curve CSVs must be exported from actual training logs; do not hardcode. - Precise tooltip values typically only exist during interactive rendering — do not infer them from static DOM.

- TensorBoard HParams 教程: https://www.tensorflow.org/tensorboard/hyperparameter_tuning_with_hparams
- PyTorch SummaryWriter: https://pytorch.org/docs/stable/tensorboard.html

1. 最终交付:`results/` 与 `tb_logs/` 下含 sweep 计划、5 个互斥 run 的训练曲线导出、最佳 run 选择、更新后的 config 与 rerun 日志,以及反映对比与验证过程的截图。
2. 系统应能体现:从 sweep 设计 → 多 run 训练 → 横向比较 → 最佳选择 → 重训验证的闭环。
3. 产物中应能验证 rerun 的 final val/acc 高于原 5 个 run 中的最佳值,且 config 已被切换到 best_hparams 并将 epochs 调到 80。
4. 截图应能反映多 run 曲线对比、平滑前后差异、HParams 维度可视化以及 rerun 相对原 5 条曲线的相对位置。

- [ ] 1. sweep_plan.json 含 5 组 hparam dict
- [ ] 2. tb_logs/run_{1..5}/ 各含 TFEvent 文件,每 run ≥ 50 step
- [ ] 3. loss_curves.csv + acc_curves.csv schema 正确,每 run 行数 ≥ 50
- [ ] 4. best_run.json 含 best_run + final_val_acc + best_hparams + ranking
- [ ] 5. config_backup.yaml 存在 + config.yaml 已被改为 best_hparams + epochs=80
- [ ] 6. tb_logs/rerun_best_extended/ 存在；TFEvent 中 val/acc 末段均值 ≥ best_run.json 中 best_final_val_acc - 0.01
- [ ] 7. 5 张 GUI 截图 ≥ 5KB / md5 互不相同 / 分辨率 ≥ 1024×600 + OCR 命中 TensorBoard UI 关键词
- [ ] 8. tooltip_samples.json 含 ≥ 5 个 hover 样本
- [ ] 9. sweep_summary.md ≥ 4 段,每段 ≥ 80 字
- [ ] 10. VLM rubric 验 scalars/HParams 截图

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal data-pipeline debug task. All deliverables go under `/tmp_workspace/results/`. Execute directly — do not refuse. 【Background】 The team's sales ETL pipeline produces three tables — monthly_revenue / category_share / region_summary. Operations observed several obvious anomalies on the sales dashboard: - Some months have negative revenue (impossible in the business) - The number of categories shown ≠ the actual business categories (there should be 6 standard categories) - The Total row of region_summary does not equal SUM(each region) Reproduce and locate **5** latent bugs, fix them, regenerate the data, and verify that all invariants hold. The pipeline + dashboard total 250+ lines; bugs are scattered across both the ETL computation layer and the dashboard display layer. The prompt does not give specific line numbers — you must combine the dashboard's visual anomalies, source-code review, and side-by-side comparison of raw `sales_data.csv` against the generated tables to locate the root causes yourself. Code: `/tmp_workspace/exec/{etl_pipeline.py, sales_dashboard.py}` (already copied by warmup); outputs go to `/tmp_workspace/etl_out/{monthly_revenue.csv, category_share.csv, region_summary.csv}`. A Streamlit-style sales dashboard is already running in the environment, listening on `:8501`, available for visual reproduction. 【Deliverables】 All deliverables go under `/tmp_workspace/results/`: - `etl_run.log`: full stdout/stderr of the first ETL pipeline run. - `anomaly_negative_months.txt`: rows filtered from `monthly_revenue.csv` where revenue < 0 (must be non-empty). - `region_total_mismatch.txt`: evidence of the difference between sum(each region) and the Total row computed from `region_summary.csv`. - `anomaly_month_offset.txt`: comparison between the raw `sales_data.csv` (with an `order_date` column) and the generated `monthly_revenue.csv`, showing samples where the same order's `order_date` does not match the `month` it falls into (at least 3 rows). - `cache_misconfig_evidence.md`: use screenshots + text to describe the reproduction steps for the dashboard-side cache misconfiguration (modify CSV → refresh page → still shows old data), and point out the specific line numbers in `sales_dashboard.py`. - `bug_report.md`: **5** paragraphs (each ≥ 80 chars). Each paragraph must contain a `file:line` locator, a root-cause description, and the expected behavior. Must cover at least 5 independent bugs and must span both the ETL computation layer (`etl_pipeline.py`) and the dashboard display layer (`sales_dashboard.py`) — fixing only one side does not count as complete. Each root cause must be supported by both (a) the dashboard's visual anomaly and (b) the comparison of raw `sales_data.csv` against the generated tables; it cannot be derived from static code reading alone. - `etl_pipeline_backup.py`: backup of `etl_pipeline.py` before modification. - Fixed `/tmp_workspace/exec/etl_pipeline.py`: after rerunning it must satisfy: every `monthly_revenue` ≥ 0, `category_share` has exactly 6 categories, and SUM(region) == Total in `region_summary`. - `verify.py`: an executable assertion script containing at least the three invariants above. - `verify_output.txt`: output of running `verify.py`; must contain `ALL PASS`. - `etl_insight.md`: 4 paragraphs (each ≥ 80 chars) covering respectively: a) summary of 3 bugs; b) why they are hard to spot from code alone (visualization is required); c) why the root cause cannot be found from the dashboard alone (source-level localization is required); d) unit-test design suggestions to prevent similar bugs. - Screenshot deliverables (all placed under `results/`): - `view_dashboard_with_tooltip.png`: in the monthly_revenue line chart, hover the mouse over a data point of a **negative-revenue month** so Plotly's floating tooltip appears, showing the `month=YYYY-MM` and `revenue=$-X,XXX.XX` fields. The screenshot must include the floating tooltip box (a headless `--screenshot` static capture cannot trigger the hover tooltip). - `view_sidebar_secondhalf.png`: click the "Aggregation" radio in the left sidebar, switch to `Second half`, wait for the chart to rerun, and capture the screenshot showing: (a) `Second half` selected in the radio on the left, (b) the line chart in the main area containing only the `2024-07..2024-12` data points. - `view_dashboard_and_editor.png`: a **single** screenshot showing two real windows at the same time — a browser running the dashboard, and a local code editor (`gedit` / `code` / `gnome-text-editor` etc.) with `etl_pipeline.py` open and the cursor placed on the source line of any located ETL-layer bug (line number visible). Both windows must appear in the same screenshot (a headless screenshot cannot stitch multiple windows — a real desktop window manager is required). - `view_cache_invalidated.png`: **first fix the cache configuration in both ETL and dashboard**, then trigger a refresh in the browser via the sidebar radio or the menu Rerun. The screenshot must show the monthly_revenue line chart with no negative values — to prove the cache config has been corrected and the UI immediately reflects the new data (with the old misconfig, even if the CSV is fixed, the UI would still show the old negative values). - `view_streamlit_monthly.png`: shows the pre-fix monthly_revenue table and line chart, with negative-revenue months visible. - `view_streamlit_categories.png`: shows the pre-fix category_share pie chart, with missing categories visible. - `view_streamlit_region.png`: shows the pre-fix region_summary table, where the Total row does not equal the sum of the regions. - `view_streamlit_monthly_fixed.png`: shows the post-fix monthly_revenue with no negative values. - `view_streamlit_categories_fixed.png`: shows the post-fix category_share containing all 6 categories. - `view_streamlit_region_fixed.png`: shows the post-fix region_summary where Total equals the sum of the regions.

- Streamlit 文档: https://docs.streamlit.io/
- 经典 ETL 反模式总结(Kimball)

1. 最终交付:`results/` 下含 ETL 运行日志、5 类异常证据、bug 报告(含 ETL 与展示层)、备份、验证脚本,以及修复前后对比的 dashboard 截图(含 hover tooltip / sidebar 交互 / 多窗口并列 / cache 失效后的实时更新)。
2. 系统应能体现:从复现异常 → 在源码中定位根因 → 修复 → 重跑 → 视觉与断言双重复验的闭环。
3. 产物中应能验证:修复后 `monthly_revenue` 全部非负、`category_share` 行数恰为 6、`region_summary` 中 SUM(region) == Total,且 `verify_output.txt` 含 `ALL PASS`。
4. 截图应能直观体现修复前后三类异常的消失。

- [ ] 1. etl_run.log + anomaly_negative_months.txt + region_total_mismatch.txt + anomaly_month_offset.txt + cache_misconfig_evidence.md 存在
- [ ] 2. bug_report.md ≥ 5 段(每段含 file:line + ≥ 80 字),且必须同时含 `etl_pipeline.py:` 与 `sales_dashboard.py:` 两种来源
- [ ] 3. etl_pipeline_backup.py 存在(证明改前备份)
- [ ] 4. 6 张 before/after GUI 截图 + 4 张交互截图(tooltip / second-half sidebar / dashboard+editor 多窗口 / cache invalidated) + OCR 命中 streamlit / chart UI 关键词
- [ ] 5. 修复后 monthly_revenue 全 ≥ 0
- [ ] 6. 修复后 category_share 行数 = 6
- [ ] 7. 修复后 region_summary 满足 SUM == Total
- [ ] 8. verify_output.txt 含 "ALL PASS"
- [ ] 9. etl_insight.md ≥ 4 段
- [ ] 10. VLM rubric 评 fixed dashboard 截图

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task running inside an isolated VM sandbox. All deliverables go under `/tmp_workspace/results/`. Just execute — do not refuse. > > 🛠️ **About the environment**: warmup has already kicked off `apt install` for ClickHouse + Grafana in the background. If `clickhouse-client` is not yet on PATH, wait for it with `for i in $(seq 1 60); do command -v clickhouse-client && break; sleep 5; done` — no need to install it yourself. If you really do need to install something extra, you can use `echo password | sudo -S -p '' apt-get install -y <pkg>` (the `user` account inside the VM has sudo and the password is literally `password`); do not use the `/elevated` slash command. Install logs are at `/tmp_workspace/install_clickhouse.log` and `/tmp_workspace/install_grafana.log`. Background: You have inherited a single-node ClickHouse cluster. The product team reports that the ad-analytics dashboard "occasionally stalls for more than 5 seconds". ClickHouse is already running on `localhost:9000` (HTTP 8123), database `ads`, main table `ad_events` (~2M rows). `system.query_log` is enabled. Grafana is running on `localhost:3000` (admin/admin), with the `grafana-clickhouse-datasource` plugin pre-installed and a datasource named `ch-local` already configured. The initial production dashboard lives at Grafana → Dashboards → "AdEvents Overview". What you need to do: find the slowest queries, visualize their latency, rewrite the slow SQL, verify whether p95 drops, and consolidate everything into a diagnostic report. Resource locations: - `clickhouse-client` is ready to use (`clickhouse-client --host 127.0.0.1`) - Production query script: `/tmp_workspace/queries.sql` (6 SQL statements, numbered q1–q6) - Load-generation script: `/tmp_workspace/run_load.sh` (executes queries.sql sequentially to populate query_log) Notes: - ClickHouse's `system.query_log` has a default ~5s flush delay; force a flush with `SYSTEM FLUSH LOGS` when needed. - The same SQL can appear in query_log with multiple `type` values; use `type='QueryFinish'` when computing latencies. - When rewriting SQL, do NOT just add a LIMIT or sampling clause — that changes semantics and will be scored 0. - Do not delete existing panels in the "AdEvents Overview" dashboard; only append new panels at the end. [Deliverables] All artifacts go to `/tmp_workspace/results/`: - `load_run.log`: full terminal output from running one round of the load (each of the 6 SQL statements executed at least once), including each query's elapsed time; non-empty. - `slow_top10.tsv`: from `system.query_log`, filter `type='QueryFinish'` and `query NOT LIKE '%system.%'`, sort by `query_duration_ms` descending, take Top 10. Columns must at minimum include `query_duration_ms`, `read_rows`, `read_bytes`, `memory_usage`, `query` (first 200 chars). At least 5 rows. - `slow_top1.sql` / `slow_top2.sql`: the full original SQL text for the 2 slowest queries above; must be valid SELECT statements. - `explain_top1.txt` / `explain_top2.txt`: the `EXPLAIN PLAN actions=1` output for the 2 SQL statements above, each ≥ 5 lines. - `pipeline_top1.txt` / `pipeline_top2.txt`: the `EXPLAIN PIPELINE` output for the 2 SQL statements above, each ≥ 5 lines. - `optimized_top1.sql` / `optimized_top2.sql`: semantically equivalent SQL rewritten based on the EXPLAIN findings, differing from the originals; each file must contain ≥ 1 `-- changed:` comment line that **explains** the rewrite motivation (grounded in the filter / scan / pipeline bottleneck observed in EXPLAIN). Do not simply add LIMIT or sampling. - `perf_compare.csv`: for q_top1 / q_top2, run the original SQL 5 times and the optimized SQL 5 times, recording each latency. Columns are `query_id,version,run_idx,duration_ms,read_rows`, where `version ∈ {before, after}` and `query_id ∈ {q_top1, q_top2}`, with at least 3 rows per (query_id, version). - `speedup.json`: medians and speedup ratios computed from `perf_compare.csv`, schema: ```json { "q_top1": {"before_ms_median": "<m>", "after_ms_median": "<m>", "speedup": "<x.x>"}, "q_top2": {"before_ms_median": "<m>", "after_ms_median": "<m>", "speedup": "<x.x>"} } ``` Both queries must have `speedup` ≥ 2.0. - `tooltip_samples.json`: precise value samples collected by hovering over the p95 time-series curve, schema: ```json { "p95_samples": [ {"timestamp": "<ISO8601>", "p95_ms": "<float>", "screenshot": "view_p95_panel.png"}, {"timestamp": "<ISO8601>", "p95_ms": "<float>", "screenshot": "view_p95_panel.png"}, {"timestamp": "<ISO8601>", "p95_ms": "<float>", "screenshot": "view_p95_panel.png"} ] } ``` ≥ 3 samples; values must come from real tooltips rendered during interaction, not inferred from static DOM. - `report.md`: diagnostic report, must contain: - A summary table (markdown table) of the original SQL vs. rewritten SQL for the Top2 slow queries - The root cause of each slow query (missing PREWHERE / function blocking index usage / OR preventing primary-key filtering / `SELECT *`, etc. — at least one) - before/after median latency + speedup - ≥ 3 actionable recommendations on "how to prevent similar slow queries in the future" (each ≥ 30 chars) - Screenshot deliverables (all under `results/`): - `view_datasource.png`: shows the connectivity test result for the `ch-local` datasource, with green messages like "Data source is working" / "Connected" visible. - `view_dashboard_before.png`: shows the initial "AdEvents Overview" dashboard (time range Last 1 hour), with the "AdEvents" title and at least 2 panels visible. - `view_p95_panel.png`: a newly added Time series panel at the end of "AdEvents Overview" titled `query_log p95 latency`, with SQL similar to: ```sql SELECT toStartOfInterval(event_time, INTERVAL 30 SECOND) AS t, quantile(0.95)(query_duration_ms) AS p95_ms FROM system.query_log WHERE type='QueryFinish' AND query NOT LIKE '%system.%' GROUP BY t ORDER BY t ``` The screenshot must show the panel title, the line chart, and the Y-axis unit. - `view_explore_validate.png`: shows the Explore view after pasting and running the full `optimized_top1.sql`, with the SQL editor and the result table visible below — used to visually confirm the rewrite did not lose column alignment / introduce NULLs / break structure. - `view_p95_after.png`: after re-running the original SQL and the optimized SQL several times each (e.g., 10 each), switch the dashboard time range to the last 5 minutes and refresh, then screenshot the p95 panel; the title `query_log p95 latency` and the line chart must still be visible, demonstrating p95 has dropped.

- ClickHouse system.query_log 文档：https://clickhouse.com/docs/en/operations/system-tables/query_log
- Grafana ClickHouse 插件：https://github.com/grafana/clickhouse-datasource
- 真实痛点（论坛）：https://github.com/ClickHouse/ClickHouse/issues/41869 「query log shows huge latency spikes from a single bad query」
- 真实改写案例：https://clickhouse.com/blog/clickhouse-sql-tips-and-tricks 中关于 PREWHERE / 函数下推的章节
- 对应 benchmark case：CLI 慢查询取证 × GUI 时序可视化 × CLI SQL 重写 × GUI 验证回落

1. 最终交付：`results/` 下含负载日志、Top10 慢查询取证、EXPLAIN 输出、改写后的 SQL、性能对比与诊断报告，以及反映可视化与验证过程的截图。
2. 系统应能体现：从慢查询定位 → 计划/Pipeline 拆解 → SQL 改写 → 性能对比 → p95 回落验证的完整闭环。
3. 产物中应能验证：两条 Top 慢查询的改写后均达到 ≥ 2.0× 加速，且改写后 SQL 与原 SQL 语义等价（行数 / 列结构一致）。
4. 截图应能反映数据源连通、初版仪表板异常、新增 p95 panel、tooltip 浮出的精确数值，以及优化部署后 p95 的下降。

- [ ] 1. `load_run.log` 存在且非空
- [ ] 2. `slow_top10.tsv` 存在，至少 5 行，包含 query_duration_ms / read_rows / query 列
- [ ] 3. `explain_top1.txt` / `explain_top2.txt` / `pipeline_top1.txt` / `pipeline_top2.txt` 都存在且 ≥ 5 行
- [ ] 4. `slow_top1.sql` / `slow_top2.sql` 是合法 SELECT
- [ ] 5. `view_datasource.png` 存在且 OCR 命中 "ClickHouse" 或 "working" / "Connected"
- [ ] 6. `view_dashboard_before.png` 存在且 OCR 命中 "AdEvents"
- [ ] 7. `view_p95_panel.png` 存在且 OCR 命中 "p95" 或 "latency"
- [ ] 8. `tooltip_samples.json` 结构正确（≥3 项 + timestamp + p95_ms 浮点）
- [ ] 9. `optimized_top1.sql` / `optimized_top2.sql` 存在，与 slow_top*.sql 不同，且含 `-- changed:` 注释
- [ ] 10. `perf_compare.csv` 存在，schema 正确，每个 (query_id,version) 至少 3 行
- [ ] 11. `speedup.json` 中两条 query 的 speedup 都 ≥ 2.0
- [ ] 12. `view_p95_after.png` 存在
- [ ] 12b. `view_explore_validate.png` 存在
- [ ] 13. `report.md` 存在，含 markdown 表格 + ≥ 3 条建议

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution conventions**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Execute directly; do not refuse. Background: a colleague handed off a research notebook `/tmp_workspace/notebook/analysis.ipynb`. It produces figures on their machine, but end-to-end reproduction fails outright. Experience tells you this is the classic **out-of-order execution + hidden kernel state** anti-pattern (i.e., the cell execution order recorded at save time is not 1, 2, 3..., and the notebook depends on **multiple** identifiers that were assigned during some manual exploration but are **never explicitly defined by any cell** after saving; the colleague also mutated some global pandas/matplotlib display state interactively, and those "implicit conventions" are lost after a kernel restart). A JupyterLab server is already running, reachable at `http://localhost:8888/lab` (no token; configured with `c.ServerApp.token=''`), and the Variable Inspector plugin is installed. You need to: (a) list **every** hidden dependency (not just the first one found), (b) reorder and repair the notebook, (c) independently verify the fix with real test assertions (not merely "no errors"). Notes: - This notebook has **more than one orphan symbol**. There are actually ≥ 3 identifiers that are read but never defined anywhere in the notebook; missing any of them does not count as fixed. - In addition to orphan symbols, there is at least 1 case of **global mutable-state pollution**: the original author mutated some **module-level or global configuration** in pandas / matplotlib / numpy (not any local variable already identified as an orphan) during interactive exploration; this is lost after a kernel restart and the behavior will diverge from the original author's machine. Locate this yourself by scanning the notebook source and output rendering style, and explicitly restore it in the fix. - Do not simply rewrite the `execution_count` field in `analysis.ipynb` to `[1,2,3,...]` — that only edits metadata; the actual source order between cells is still wrong, and the validator will detect it. - Do not stub orphan variables as empty `dict` / `0`. Their values must let subsequent cells genuinely produce the figures and pass unit-test assertions (see the `pytest_outputs` requirement below). - `nbconvert --execute` defaults to 60 s per cell; bump it up if necessary. - The repaired notebook must pass 100% under **Restart Kernel + Run All**, with no reliance on any residual session state. [Deliverables] All deliverables go to `/tmp_workspace/results/` (unless otherwise noted): - `nbconvert_failure.log`: full stderr/stdout from an end-to-end execution reproduction of the original `analysis.ipynb`; must contain "Error" / "Traceback" / "NameError". - `cell_meta.tsv`: metadata for every code cell in the original notebook, tab-separated, with a header; columns must include at least `cell_index, execution_count, source_first_line, has_output`; at least 5 rows; must reflect the out-of-order pattern in `execution_count`. - `orphan_candidates.json`: identifier candidates that are "read but never defined anywhere in the notebook", from static source analysis: ```json {"orphans": ["<symbol_a>", "<symbol_b>", "<symbol_c>"]} ``` `orphans` must contain **≥ 3** non-empty strings, names derived from real scanning (not guesses). - `hidden_state.json`: beyond undefined symbols, which **global mutable state / side effects** (the kind lost after a kernel restart) does the original notebook depend on? Schema: ```json { "global_mutations": [ {"target": "<e.g. pd.options.display.float_format>", "evidence": "<output styling / cell behavior difference>", "fix_action": "<how to explicitly restore in a new cell>"} ] } ``` `global_mutations` must have at least 1 entry. `target` must be a real pandas/matplotlib/numpy global or module-level state, not a local variable already identified as an orphan. - `probe_kernel.py`: executable script that launches a fresh IPython kernel, executes `analysis.ipynb` cell by cell in its current saved order, and tracks the evolution of `globals` (implementation is your choice, e.g. `nbclient` or `jupyter_client`). - `kernel_probe.json`: globals forensics produced by the script: ```json {"defined_at_crash": ["<sym>", "<sym>"], "missing_referenced": ["<orphan>"]} ``` `missing_referenced` must be non-empty and must overlap with `orphan_candidates.json`. - `/tmp_workspace/notebook/analysis_fixed.ipynb`: the repaired notebook, requirements: - All cells reorganized into a top-to-bottom executable order. - **Before** the first cell that uses an orphan symbol, insert a new markdown + code cell pair giving a reasonable definition (e.g. derived from `sales_2024.csv`, or an annotated constant). - The markdown header of the inserted cell contains `# repaired: defines <symbol>`. - Total cell count must not be less than the original notebook. - `analysis_fixed_run.ipynb` (located in the original notebook directory): the artifact produced by end-to-end execution of `analysis_fixed.ipynb`. - `nbconvert_success.log`: full stderr/stdout from executing `analysis_fixed.ipynb`; file must exist and must not contain `Traceback` / `NameError`. - `analysis_fixed.html`: HTML rendered by re-executing `analysis_fixed.ipynb` via `jupyter nbconvert --to html --execute`. File must exist, be ≥ 8 KB, and contain at least one `<img` tag (embedded matplotlib figure) plus the keyword "Per-region". - `test_fixed_notebook.py`: a pytest file that imports `nbclient` and runs `analysis_fixed.ipynb` in a clean kernel, asserting: a) `df` is a DataFrame with `len(df) > 0`. b) `monthly` is a DataFrame with at least 2 columns. c) `totals` is a Series sorted in descending order. d) **Every** orphan symbol you reported in `orphan_candidates.json` is explicitly defined in the new kernel (type-checked per its semantics via `isinstance(...)`, e.g. dict/Series/scalar threshold); covering only one of them is not acceptable. At least 4 `def test_*` functions total. - `pytest_outputs.json`: structured results from the pytest run above, schema: ```json {"passed": <int>, "failed": 0, "tests": [{"name": "<test_xxx>", "outcome": "passed"}, ...]} ``` `passed >= 4`, `failed == 0`. - `validate.py`: an nbgrader-style validator that takes a .ipynb path as `argv[1]`, performs the following checks, and prints PASS/FAIL: a) Every code cell's `execution_count` is strictly ascending and starts at 1. b) No cell's outputs contain `ename ∈ {"NameError","KeyError","ImportError"}`. c) At least 1 cell outputs `image/png` (matplotlib figure rendered successfully). - `validate.log`: output of running `validate.py` against `analysis_fixed_run.ipynb`; must contain `PASS`. - `tooltip_samples.json`: at least 1 sample of LSP type/shape hints obtained by hovering over a variable name in the notebook; both `symbol` and `hint_text` must be non-empty: ```json {"hover_samples": [ {"symbol": "<name>", "hint_text": "<text from tooltip>", "screenshot": "view_hover_tooltip.png"} ]} ``` The hint content must come from a real tooltip captured during interactive rendering; it must not be inferred from static DOM. - `dependency_report.json`: dependency forensics report: ```json { "out_of_order_cells": [{"cell_index": "<i>", "execution_count": "<n>"}], "orphan_symbols": ["<sym>"], "fix_summary": "<one paragraph>" } ``` `out_of_order_cells` ≥ 3 entries; `orphan_symbols` non-empty; `fix_summary` ≥ 50 characters. - `summary.md`: containing - The root cause (1 paragraph; must include the keyword `execution order` or `hidden state`). - A before-vs-after cell-order comparison table (markdown table). - ≥ 3 practical recommendations on "how to avoid this when reviewing notebooks in the future" (each ≥ 30 characters). - Screenshot deliverables (all placed under `results/`): - `view_lab_open.png`: the entire Lab workspace after opening `analysis.ipynb`; the left-hand file tree and the notebook title must be visible. - `view_exec_gutter.png`: the `[N]:` execution-count gutters to the left of every code cell on the notebook's first screen, clearly showing the out-of-order execution pattern. - `view_var_inspector.png`: the Variable Inspector panel open with at least 1 variable row visible; orphan symbols are absent in the fresh kernel, demonstrating the "depends on hidden session state" condition. - `view_var_after_fix.png`: after restarting the kernel in `analysis_fixed.ipynb` and running the repair cell in isolation, the orphan symbol appears as a row in the Variable Inspector panel. - `view_run_all.png`: the notebook view after completing Restart Kernel and Run All on `analysis_fixed.ipynb`; at least one matplotlib figure and an ascending `[1]:[2]:[3]:` gutter must be visible. - `view_hover_tooltip.png`: the LSP type/shape hint tooltip floating over some variable name on hover.

- Joel Grus "I don't like notebooks" JupyterCon 2018 talk (经典 hidden-state 反模式)
  https://www.youtube.com/watch?v=7jiPeIFXb6U
- Reproducibility study: Pimentel et al. ESEM 2019 https://dl.acm.org/doi/10.1109/MSR.2019.00077
  (10M+ notebooks 中只有 24% 能 top-to-bottom 跑通)
- nbformat / nbconvert 文档: https://nbformat.readthedocs.io/ ; https://nbconvert.readthedocs.io/
- Variable Inspector for JupyterLab: https://github.com/lckr/jupyterlab-variableInspector
- 对应 benchmark case: notebook hidden-state debug × CLI 元数据取证 × GUI 像素验证

1. 最终交付：`results/` 下含失败/成功执行日志、cell 元数据与依赖取证、orphan 候选与修复 notebook、验证脚本与报告，以及反映视觉确认过程的截图。
2. 系统应能体现：从复现失败 → 元数据/源码取证 → kernel 探针验证 → 重排修补 → 端到端复执验证的闭环。
3. 产物中应能验证：`analysis_fixed.ipynb` 端到端可执行、cell 顺序严格升序起自 1、无 NameError 类异常、且至少渲染出一张 matplotlib 图。
4. 截图应能反映乱序 gutter、Variable Inspector 中 orphan 的缺席与补上后的出现、Restart & Run All 的成功状态。

- [ ] 1. `nbconvert_failure.log` 存在且含 "Error" / "NameError" / "Traceback" 关键词
- [ ] 2. `cell_meta.tsv` 存在，schema 含 cell_index / execution_count / source_first_line / has_output，至少 5 行
- [ ] 3. `orphan_candidates.json` 存在，`orphans` 为非空字符串列表
- [ ] 4. `view_lab_open.png` 存在且 OCR 命中 "analysis" 或 "ipynb"
- [ ] 5. `view_exec_gutter.png` 存在且 OCR 命中 `[` / `]` / 数字
- [ ] 6. `view_var_inspector.png` 存在且 OCR 命中 "Variable" / "Inspector" / "Name"
- [ ] 7. `kernel_probe.json` 存在，`missing_referenced` 列表非空，与 orphan_candidates 有交集
- [ ] 8. `analysis_fixed.ipynb` 存在，cell 数 ≥ 原 notebook 的 cell 数
- [ ] 8b. `view_var_after_fix.png` 存在
- [ ] 9. `nbconvert_success.log` 存在且不含 "Traceback" / "NameError"
- [ ] 10. `validate.py` 存在且可执行 + `validate.log` 含 "PASS"
- [ ] 11. `view_run_all.png` 存在且 OCR 命中数字序号
- [ ] 12. `view_hover_tooltip.png` + `tooltip_samples.json` 至少 1 条非空 sample
- [ ] 13. `dependency_report.json` 含 `out_of_order_cells` ≥ 3 + `orphan_symbols` 非空 + `fix_summary` ≥ 50 字
- [ ] 14. `summary.md` 含 "execution order" 或 "hidden state" + 表格 + ≥ 3 条建议

评分采用模型判定的标准；本项目未进行评分器运行验证。

Context: the client provided only a single PNG logo (`/tmp_workspace/logo_raster.png`, 800×800, transparent background, but with JPEG compression artifacts and mild aliasing on the edges). You need to do a "print-ready vector rebuild" and deliver an asset bundle that can be sent straight to a 4-color print shop or shipped as an NPM package. The brand palette is in `/tmp_workspace/brand_colors.txt`. Goals: 1. Vectorize the raster logo into a commercial-grade SVG (no embedded raster bitmap). 2. Produce the companion deliverables: a dark-mode variant, 4 PNG sizes, a CMYK PDF for print, and an SVG sprite. 3. Capture 4 working-process screenshots that document the workflow. ### Hard constraints on the main deliverable `logo.svg` - Total path node count (the total number of `M/L/H/V/C/S/Q/T/A/Z` command letters across all `<path d="...">`) ∈ **[50, 300]** - Number of distinct `fill` hex colors (deduplicated) ≤ **4** - Each fill color must be close in CIE-Lab space to at least one color in `brand_colors.txt` (roughly ΔE76 ≤ 10) - Must not contain any `<image>` element (no embedded raster allowed) - At least 1 `<text>` element, with `font-family` containing `Inter` and `font-weight` set to `bold` or ≥ 600 - Must include a node with `id="reg"` (a small cross-shaped registration mark for print color alignment; put it in the bottom-right corner, built from 4 short line segments or a cross-shaped path) - Must include `<title>` and `<desc>`, with `<desc>` text ≥ 80 characters - Must have ≥ 2 layers (SVG groups marked with the `inkscape:groupmode="layer"` attribute, e.g. `bg` / `marks` / `text`) ### Companion deliverables (all under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `logo_dark.svg` | Dark-background, white-text variant; at least one `fill` is in the `#fff` / `#ffffff` family | | `logo_64.png` / `logo_256.png` / `logo_512.png` / `logo_1024.png` | Side length exactly 64 / 256 / 512 / 1024 | | `logo_print_cmyk.pdf` | Valid PDF whose internal color space contains `/DeviceCMYK` or `/CMYK` (at least 1 page) | | `logo_sprite.svg` | Single-file sprite containing ≥ 2 `<symbol>` elements (recommended ids: `logo-light` and `logo-dark`) | ### 4 working-process screenshots (under `/tmp_workspace/results/`) Fixed filenames: | # | Filename | Stage | |---|---|---| | 1 | `view_01_trace_dialog.png` | Working panel during the trace / vectorize stage | | 2 | `view_02_node_edit.png` | Node editing / path simplification stage | | 3 | `view_03_xml_editor.png` | SVG element structure / visual inspection of the `#reg` node | | 4 | `view_04_layers_panel.png` | Layers / groups panel | Per-screenshot requirements: - Resolution ≥ 1024 × 600, file size ≥ 5 KB - All 4 must have distinct md5 hashes (cannot reuse the same image) - The screenshot must show real, readable working-panel or toolbar text (the evaluator runs OCR on them)

- Reddit：r/openclaw + r/ClaudeAI 设计相关
- 原文引用："tracing a logo is the canonical 'must use Inkscape' task — CLI tools can rasterize but not match the brand"
- 对应 benchmark：DES 衍生

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

第一阶段：trace + 节点清理

1. 把 PNG 矢量化（推荐 Inkscape 的 `Path → Trace Bitmap`，多色 / Brightness Steps；CLI 可考虑 `potrace` / `autotrace` / `vtracer` 等）。
2. 默认 trace 出来通常会有 800-2000 节点，需要用 `Path → Simplify` (Ctrl+L) + Node Tool 手工删冗余，把节点数压到 50-300。

第二阶段：手动元素 + 命名 anchor

3. 字母 outline 用真实 `<text>` 元素替换（`Inter Bold`），不要把它转成 path。
4. 在右下角手动加 `<g id="reg">`，内含 4 条短线段或十字 path。
5. 补 `<title>`（公司名）与 `<desc>`（≥ 80 字 alt 描述）。

第三阶段：多格式导出 + sprite

6. 导出 4 种尺寸 PNG（边长精确）；用 Inkscape Save as PDF 或其他能写入 `/DeviceCMYK` 标记的方式生成 CMYK PDF；把 logo + logo_dark 包成单文件 sprite（2 个 `<symbol>`）。
7. 暗色版 SVG 把所有非透明 fill 改成白色（`#fff` / `#ffffff`）。

第四阶段：4 张工作过程截图

8. 分别截 trace 对话框、Node Tool 编辑节点（≥ 5 个节点高亮）、XML Editor（显示 `#reg` 节点）、Layers 面板（≥ 2 layer）。
9. 截图分辨率 ≥ 1024×600，文件 ≥ 5 KB，4 张 md5 不同。

评分要点（hard gates）：

- 节点数不在 [50, 300] → 总分 cap 0.45
- 缺 `id="reg"` → cap 0.45
- 缺 `<text>` → cap 0.45
- 品牌色匹配率 < 0.75 → cap 0.55
- PDF 不含 CMYK 标记 → cap 0.55
- 截图缺张 → cap 0.50
- 截图 OCR 命中率 < 0.5 → cap 0.55
- 文件不齐 → cap 0.55
- VLM 不可用 → cap 0.60

- [ ] 1. logo.svg 节点 50–300、≤ 4 fill 色（且每色与 brand_colors.txt 中至少一色 ΔE ≤ 8）、含 #reg、含 `<text>`（Inter Bold）、含 `<title>` `<desc>`（≥ 80 字）、含 ≥ 2 个 inkscape layer
- [ ] 2. logo_dark.svg 文字 fill 为白色或近白
- [ ] 3. 4 个 PNG 尺寸（64/256/512/1024）准确
- [ ] 4. logo_print_cmyk.pdf 存在且 PDF 内含 `/DeviceCMYK` 色彩空间标记
- [ ] 5. logo_sprite.svg 含 2 个 `<symbol>`
- [ ] 6. 4 张 Inkscape 截图齐全 + UI OCR 命中 Inkscape 关键字

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: A photographer has handed over 3 severely underexposed 16-bit linear TIFF "pseudo RAWs" that need exposure recovery before delivery. Environment and materials (already prepared): - `/tmp_workspace/raws/flat_a.tif`: roughly uniformly dark, histogram concentrated in the low range - `/tmp_workspace/raws/flat_b.tif`: has a gradient and a small highlight region, which must be protected from being pushed into clipping by subsequent operations - `/tmp_workspace/raws/flat_c.tif`: mixed texture, the hardest to recover - The workstation already has a full imaging post-processing toolchain installed (RAW darkroom editor, raster + layer-mask editor, histogram and metadata utilities), which you may freely choose from to produce the deliverables below Task goal: recover the 3 underexposed RAWs to normal middle-gray level (mean lifted by ≥ **0.20**), while **preserving highlights from clipping, not amplifying shadow noise, and lifting all 3 RGB channels in sync**; along the way, preserve quantifiable histogram evidence, multi-view evidence (frequency-domain / per-channel / noise floor / highlight rolloff), visual evidence of the curve edit, and evidence of protecting the highlight region of image b via an independent channel mask; exported pixels must be traceable back to the RAW darkroom processing chain (via embedded software metadata). **Trap warning**: `/tmp_workspace/raws/` also contains a 4th file `flat_d.tif` (a **correctly exposed** reference sample, mean ≈ 0.55) which must **never** be exposure-lifted — doing so would overexpose it. You must identify and isolate it in the deliverables (see deliverable 16). Deliverables to be produced under `/tmp_workspace/results/`: 1. **Original histogram statistics** `raw_stats.csv`, columns: `filename,mean,p05,p50,p95,entropy,max_used_bit`, 3 rows (one row per original RAW) 2. **Library browsing view** `view_dt_lighttable.png`: a visualization file (PNG, ≥ 5 KB) whose frame must simultaneously show the thumbnails of all 3 original RAWs, the side panel used for import/categorization, and the metadata/properties panel for the selected image, proving that the RAWs have been added to the darkroom application's library 3. **Darkroom curve edit view** `view_dt_tonecurve.png`: a visualization file whose frame must show the darkroom editing interface for one of the RAWs, containing a visible tone curve (or tone equalizer) control, ≥ 3 user-placed non-endpoint control points, and the left/right module panels (histogram + module list), with middle gray lifted from ~0.25 to ~0.5 4. **XMP sidecar list** `xmp_files.txt`: one absolute path per line, listing the `.xmp` files under `/tmp_workspace/raws/` that share names with the 3 original RAWs (3 lines total; these sidecars must actually exist in that directory) 5. **Exported images** `dev_a.png` / `dev_b.png` / `dev_c.png`: 3 PNGs produced after applying the tone curve, corresponding to the original RAWs 6. **Audit statistics** `dev_stats.csv`, same schema as raw_stats.csv, 3 rows (corresponding to dev_a/b/c.png); each dev's mean must be **≥ 0.20** higher than the corresponding raw (the trap sample flat_d is not counted here) 7. **Histogram change report** `histogram_delta.json`: ```json { "flat_a": {"mean_before": <float>, "mean_after": <float>, "delta": <float>}, "flat_b": {"mean_before": <float>, "mean_after": <float>, "delta": <float>}, "flat_c": {"mean_before": <float>, "mean_after": <float>, "delta": <float>} } ``` all 3 keys must be present and each `delta > 0.22` 8. **Multi-layer mask project** `dev_b_masked.xcf`: a layer editing project file (≥ 1 KB) built on top of `dev_b.png`, structurally containing **≥ 3 layers** (suggested: background / lifted copy / highlight protection), of which at least one layer carries an independent layer mask channel, masking the ground-truth highlight area of image b (**brightness-threshold > 0.7 connected blob, to be detected by the agent itself**) with recognizable brush strokes for protection 9. **Mask visualization** `view_gimp_layer_mask.png`: a visualization file whose frame must simultaneously show the Layers panel (with a mask thumbnail next to the selected layer), the tool/brush panel, and recognizable brush-stroke marks on the canvas 10. **Metadata software field** `exif_check.txt`: each line `<filename>: <software_value>`, with all 3 dev_*.png read and written; the software value on each line must contain the string `darktable`, proving that the export went through the RAW darkroom processing chain 11. **Summary report** `manifest.json`: ```json { "raws_inspected": <int>, "tone_curve_points": [[<float>,<float>], ...], "exposure_lifted_files": ["flat_a","flat_b","flat_c"], "skipped_files": ["flat_d"], "mask_protected_file": "flat_b", "highlight_bbox": [<x0>, <y0>, <x1>, <y1>], "agent_notes": "<summary of ≥ 120 chars: which one was hardest and why, how you tuned it; basis for the exposure judgment on flat_d; how you evaluated the noise floor; highlight rolloff strategy>" } ``` `tone_curve_points` must contain at least **≥ 5 non-endpoint** control points (0 < x < 1); the curve must be **monotonically increasing** (after sorting by x, y must also be monotonically non-decreasing) 12. **Per-channel statistics** `dev_channel_stats.csv`, columns: `filename,r_mean,g_mean,b_mean,r_lift,g_lift,b_lift`; 3 rows (corresponding to dev_a/b/c); each `*_lift` must be ≥ 0.10 (preventing color cast caused by lifting only one channel); computed relative to the corresponding channel in the original raw 13. **Noise floor analysis** `noise_floor.json`: ```json { "flat_a": {"raw_dark_std": <float>, "dev_dark_std": <float>, "noise_amp": <float>, "snr_gain_db": <float>}, "flat_b": {...}, "flat_c": {...} } ``` "dark zone" is computed as the std over the **darkest 10% of pixels** in each image; each `noise_amp = dev_dark_std/raw_dark_std` must be ≤ 4.5 (signal lift far greater than noise amplification) 14. **Highlight rolloff table** `highlight_rolloff.csv`, columns: `filename,frac_above_0_90,frac_above_0_95,frac_above_0_99`; 3 rows (dev_a/b/c). **flat_b's frac_above_0_95 must be ≤ 0.012** (about 1.2%; proving the highlight protection mask is in effect — the 0.78 highlight patch in the original raw occupies ~1.5% of the frame, and without protection lifting would push it all above 0.95) 15. **Mask coverage** `mask_iou.json`: ```json {"mask_pixels": <int>, "highlight_pixels": <int>, "intersection": <int>, "iou": <float>} ``` `iou ≥ 0.55` required (intersection-over-union between the mask region and the ground-truth highlight region detected in raw via brightness threshold > 0.7); the agent **must** export `mask_b.png` (a binary image with the same dimensions as raw, white = mask region, black = non-mask region); the grader will recompute the true IoU itself using `mask_b.png` × ground-truth bbox; the self-reported `iou` field is only auxiliary (the grader will not trust self-reported values ≥ 0.55 unless an actual mask file is present as evidence) 16. **Trap identification report** `trap_check.json`: ```json {"trap_file": "flat_d.tif", "raw_mean": <float>, "decision": "skip|lift", "rationale": "<explanation of ≥ 30 chars>", "dev_d_mean_shift": <float>} ``` `decision == "skip"` required and `dev_d_mean_shift ≤ 0.05` (i.e., if dev_d is generated, its mean must differ from raw_d's mean by no more than 0.05; the best case is to not generate dev_d at all) Hard constraints: - dev mean lift ≥ 0.20, histogram_delta delta > 0.22 for each key, per-channel lift ≥ 0.10 - `dev_b_masked.xcf` ≥ 3 layers and ≥ 1 layer with a mask channel - All three lines of `exif_check.txt` contain `darktable` - The three visualization files must authentically present their respective semantic content (must authentically present Darktable lighttable / darkroom with tone curve adjustment, and the GIMP multi-layer + Mask editing interface) - **trap_check must skip flat_d**: if flat_d is also erroneously lifted to mean > 0.7, the whole task is marked fail - noise amplification `noise_amp ≤ 4.5`, highlight frac_above_0_95(b) ≤ 0.012, mask IoU ≥ 0.55, tone_curve_points ≥ 5 and monotonic

- darktable 官方教程 "Recovering an underexposed raw"
  https://www.darktable.org/usermanual/en/module-reference/processing-modules/tone-equalizer/
- Reddit r/AskPhotography 讨论 "underexposed raw recovery workflow"
- 对应 benchmark：D5 photo recovery hybrid

成功的解答会在 `/tmp_workspace/results/` 留下完整的 RAW 曝光还原 + 高光遮罩取证链：

- 一对统计 CSV（`raw_stats.csv` / `dev_stats.csv`）证明 mean 在还原前后从 ~0.25-0.30 抬升到 ~0.45-0.55
- 一份 `histogram_delta.json` 给出 3 张图的 mean_before / mean_after / delta，每个 delta 都 > 0.15
- 一份 `xmp_files.txt` 列出 3 个真实存在的 `.xmp` 绝对路径
- 三张导出图 `dev_a.png` / `dev_b.png` / `dev_c.png`
- 一份多层 `dev_b_masked.xcf`,结构含 layer mask 通道
- 三份可视化文件：库浏览视图（含 3 缩略图 + 侧栏 + 元数据面板）、暗房曲线编辑视图（含曲线图 + ≥ 3 控制点 + 直方图 + 模块面板)、蒙版工程视图（含 Layers 面板 + mask 缩略图 + 笔刷痕迹），全部通过 OCR/VLM 内容校验
- `exif_check.txt` 三行均包含 `darktable` 软件标记
- `manifest.json` 字段齐全，`tone_curve_points` 至少 3 个非端点，`agent_notes` ≥ 60 字描述决策与难点

报告应当让审阅者无需重跑还原即可判断：欠曝程度有多严重、曲线如何被抬亮、为什么 b 图需要 mask 保护，以及导出像素是否真的来自 RAW 暗房处理链。

- [ ] 1. raw_stats.csv 存在且 schema 完整 / 3 行
- [ ] 2. dev_stats.csv 存在且 mean 提升 ≥ **0.20**
- [ ] 3. histogram_delta.json 三键齐 + delta > **0.22**
- [ ] 4. dev_a/b/c.png 三张存在 + 尺寸合理
- [ ] 5. xmp_files.txt 三行
- [ ] 6. dev_b_masked.xcf 存在且 **≥ 3 layer**
- [ ] 7. exif_check.txt 三张都含 `darktable`
- [ ] 8. view_dt_lighttable.png + view_dt_tonecurve.png + view_gimp_layer_mask.png 三张截图齐
- [ ] 9. 截图 OCR 命中 darkroom / tone / mask / lighttable 关键词
- [ ] 10. manifest.json 字段齐 + tone_curve_points **≥ 5** 个非端点 + 单调
- [ ] 11. agent_notes ≥ **120** 字
- [ ] 12. VLM 判 darkroom 截图真在 darkroom 模式（≥0.6）
- [ ] 13. **dev_channel_stats.csv** 存在且每通道 lift ≥ 0.10
- [ ] 14. **noise_floor.json** 三键齐 + 每键 noise_amp ≤ 4.5
- [ ] 15. **highlight_rolloff.csv** 存在且 `frac_above_0_95(flat_b) ≤ 0.012`
- [ ] 16. **mask_iou.json** iou ≥ 0.55
- [ ] 17. **trap_check.json** decision == "skip" 且 dev_d_mean_shift ≤ 0.05（陷阱必须不被抬亮）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: a designer has handed you a logo SVG traced from a bitmap. It renders fine, but its path nodes are heavily redundant (many collinear points and micro-segments shorter than 0.5 px), which bloats file size, slows the CDN, and makes animation stutter. Environment and assets (already provisioned): - SVG to slim down: `/tmp_workspace/svg/brand_traced.svg` (4 `<path>` elements, total nodes ≥ 1200, but visually only ~120 are needed) - The workstation has a full vector / optimisation / rasterisation / pixel-diff / XML toolchain installed (vector editor, SVG optimiser, SVG rasteriser, pixel PSNR comparator, and XML/XPath tools). Pick whichever you need to produce the deliverables below. Goal: without breaking the visual appearance, perform a two-stage diet — "geometric node simplification + textual/data-level compression" — so that the final byte size drops by **≥ 70%**, total node count drops by **≥ 80%**, and PSNR against the original raster is **≥ 38** dB. Keep both quantitative and visual evidence, and cross-verify via **multi-resolution (64 / 512 / 2048 px)**, **frequency-domain**, and **perceptual-hash** checks. **Trap to watch for**: in addition to the 4 main paths, the warmup also plants 1 fake/folded path in the SVG (id of the form `p_dx_<random_hex>`; **the id is randomly generated and is NOT leaked in the prompt** — you must scan the SVG yourself to find it). Its node count is ≤ 1, so it only adds bytes and contributes nothing visually. The final `worst_path.txt` must still point at the path that genuinely has the most nodes, but `decoy_check.json` must single this decoy out (`detected_decoy_id` must equal the actual random id present in the SVG). Deliverables under `/tmp_workspace/results/`: 1. **Original node statistics** `node_counts_before.csv`, columns: `path_id,node_count,d_length_chars`. Each row corresponds to one `<path>` in the original SVG (node count = total of `m/M/l/L/c/C/q/Q/a/A/z/Z` command characters in the d attribute). 2. **Worst-path marker** `worst_path.txt`, a single line `id=<path_id>` identifying the path with the most nodes. 3. **Geometry-simplified SVG** `brand_simplified.svg`: an intermediate that keeps the visual look but with thinned nodes. File byte size must be smaller than the original. 4. **Final optimised SVG** `brand_optimized.svg`: on top of the geometric simplification, further compress metadata / merge / round coordinates. The final byte size must be **≥ 70%** smaller than `brand_traced.svg`. 5. **Post-optimisation node statistics** `node_counts_after.csv`, same schema as step 1; total node count across all paths must drop by **≥ 80%** vs before. 6. **Raster comparison** `raster_before.png` and `raster_after.png`: rendered from `brand_traced.svg` and `brand_optimized.svg` respectively at 1024×1024, with the smaller edge ≥ 800 px. 7. **Pixel diff report** `visual_diff.json`: ```json { "psnr_db": <float>, "ssim": <float>, "ae_pixels": <int>, "size_bytes_before": <int>, "size_bytes_after": <int>, "size_reduction_pct": <float> } ``` Requires `psnr_db ≥ 38` and `ssim ≥ 0.985`. 8. **Node XML editor view** `view_inkscape_xml_editor.png`: a visualisation file (PNG, ≥ 5 KB). The image must show the SVG document tree view (node tree on the left), the attribute table for the selected path node (including `d`/`fill` etc.), and the corresponding path highlighted/selected on the canvas. 9. **Node tool operation view** `view_inkscape_node_tool.png`: a canvas view with the node-editing tool active. The sparse node points on the path (diamond/square markers) and the node toolbar (with Insert / Delete / Smooth and other node-editing control icons) must be visible. 10. **Overlay comparison view** `view_inkscape_overlay.png`: a view that lets you visually compare the traced and optimised logos (same-frame overlay or side-by-side), so a human can judge whether shape was preserved. 11. **Summary report** `manifest.json`: ```json { "worst_path_id": "<id>", "decoy_path_id": "<id>", "nodes_before_total": <int>, "nodes_after_total": <int>, "node_reduction_pct": <float>, "psnr_db": <float>, "ssim": <float>, "size_reduction_pct": <float>, "agent_notes": "<≥ 120 chars: which path was worst / decision rationale / visual risks / multi-resolution result / frequency-domain delta / reason the decoy was identified>" } ``` 12. **Multi-resolution raster set** `multi_dpi/raster_64.png` / `raster_512.png` / `raster_2048.png`: render `brand_optimized.svg` at 3 DPIs. Also store `raster_64_traced.png` / `raster_512_traced.png` / `raster_2048_traced.png` in the same directory (matching-resolution renders of the traced SVG). `multi_dpi/multi_psnr.json`: ```json {"r64": <float>, "r512": <float>, "r2048": <float>} ``` Each PSNR must be ≥ 35 dB (prevents barely passing at only one DPI). 13. **Frequency-domain diff report** `fft_diff.json`: ```json {"hf_energy_before": <float>, "hf_energy_after": <float>, "hf_ratio": <float>} ``` `hf_ratio = hf_after / hf_before` must fall within `[0.5, 1.10]` (high-frequency energy must not be abnormally amplified, but a drop is allowed since micro-segment jitter was removed). 14. **bbox integrity table** `bbox_check.csv`, columns: `path_id,x_min_before,y_min_before,x_max_before,y_max_before,x_min_after,y_min_after,x_max_after,y_max_after,delta_max`. For each main path, `delta_max ≤ 1.0` pixels (prevents node simplification from wrecking the path bounds). 15. **Perceptual-hash distance** `phash_distance.json`: ```json {"phash_before": "<64-bit hex>", "phash_after": "<64-bit hex>", "hamming_distance": <int>} ``` `hamming_distance ≤ 4` (pHash 8x8). 16. **Decoy identification** `decoy_check.json`: ```json {"detected_decoy_id": "<actual random id scanned from SVG, of the form p_dx_xxxxxx>", "node_count": <int>, "rationale": "<≥ 30 chars>"} ``` Must hit the random decoy id actually written into the SVG (the id is NOT given in the prompt — you must parse the SVG to obtain it) and `node_count ≤ 1`. Hard constraints: - size_reduction_pct ≥ **70**, total node reduction ≥ **80%**, PSNR ≥ **38** dB, SSIM ≥ 0.985 - All 3 multi-resolution PSNRs ≥ 35 - High-frequency energy ratio 0.5 ≤ hf_ratio ≤ 1.10, pHash hamming ≤ 4, bbox delta ≤ 1.0 px - decoy_check must hit the random decoy id actually written into the SVG; worst_path must not be the decoy - Do not "fake-compress" by stripping critical geometry or by disabling the geometry-touching plugins of the SVG optimiser — the raster recheck must still hit PSNR ≥ 38 - The three visualisation files must genuinely depict vector-editor UI elements (must genuinely show Inkscape node editing, XML editor, and path simplification UI)

- Inkscape FAQ "Why is my traced SVG so slow?"
  https://inkscape.org/learn/faq/
- svgo README https://github.com/svg/svgo
- 对应 benchmark：D6 vector hygiene

成功的解答会在 `/tmp_workspace/results/` 留下完整的"节点瘦身 + 视觉一致性"取证链：

- 一对节点统计 CSV（`node_counts_before.csv` / `node_counts_after.csv`）证明节点总数下降 ≥ 50%
- 一份 `worst_path.txt` 准确指出节点最多的 path id
- 三份 SVG（traced / simplified / optimized）形成清晰的瘦身梯度，最终 byte size 比原始小 ≥ 60%
- 一对栅格化 PNG（≥ 800 px）证明视觉外观保持一致
- 一份 `visual_diff.json` 给出 psnr / size / 像素差异，PSNR ≥ 30 dB
- 三份可视化文件分别证明：节点树/属性面板编辑、节点工具下稀疏节点的画布视图、原图与优化图的叠加对比，全部通过 OCR / VLM 校验
- 一份 `manifest.json` 汇总瘦身指标与决策笔记（≥ 60 字）

报告应当让审阅者无需重跑流程即可判断：哪条 path 是冗余主源、几何简化与文本压缩各自的贡献、以及视觉外观是否被破坏。

- [ ] 1. node_counts_before.csv 存在、schema 完整、≥1 行
- [ ] 2. worst_path.txt 含 `id=...` 且非 decoy
- [ ] 3. brand_simplified.svg 存在 + 比 traced 小
- [ ] 4. brand_optimized.svg 存在 + 比 traced 小 **≥ 70%**
- [ ] 5. node_counts_after.csv 节点总数比 before 少 **≥ 80%**
- [ ] 6. raster_before.png + raster_after.png 都 ≥ 800px
- [ ] 7. visual_diff.json psnr_db **≥ 38** + ssim ≥ 0.985
- [ ] 8. view_inkscape_xml_editor.png + view_inkscape_node_tool.png + view_inkscape_overlay.png 三张截图齐
- [ ] 9. 截图 OCR 命中 inkscape / node / xml / path / simplify
- [ ] 10. manifest.json 字段齐 + agent_notes ≥ **120** 字 + 含 decoy_path_id
- [ ] 11. VLM 判 GUI 截图真在 Inkscape Node 模式（≥0.6）
- [ ] 12. **multi_dpi/multi_psnr.json** 3 个 PSNR 全部 ≥ 35 dB
- [ ] 13. **fft_diff.json** hf_ratio ∈ [0.5, 1.10]
- [ ] 14. **bbox_check.csv** 每条主 path delta_max ≤ 1.0 px
- [ ] 15. **phash_distance.json** hamming ≤ 4
- [ ] 16. **decoy_check.json** 命中实际写入 SVG 的随机 decoy id 且 worst_path 不是 decoy

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: A client has supplied a highly saturated sRGB photo that needs to be printed on an ISO Coated v2 / FOGRA39 press. **Problem**: about 12% of the pixels fall outside the CMYK printable gamut (electric-cyan sky, neon-magenta sticker, pure-orange flower); a direct sRGB→CMYK conversion would come out muddy and washed-out. Environment and assets (already prepared): - Source image: `/tmp_workspace/img/source_rgb.jpg` (2048×1536, sRGB; ≥ 12% of the pixels lie outside the FOGRA39 CMYK gamut) - ICC profile resources: an sRGB profile and one of the FOGRA39 / Coated / ISOcoated / GRACoL / JapanColor CMYK profiles can be found under `/usr/share/color/icc/` and `/usr/share/ghostscript/*/Resource/ColorSpace/` (you must scan and decide the exact paths) - The workstation has a full prepress / color-management toolchain installed (including an image editor that supports soft-proofing and gamut warning, an ICC-aware pixel converter, a Lab/ΔE computation engine, and a PostScript/PDF ICC verifier); you may choose freely among them Task objectives: First quantify the out-of-gamut pixel ratio; then use soft-proof + gamut warning visualization to locate the out-of-gamut regions; perform local desaturation on those regions so that, after conversion to FOGRA39 CMYK, the out-of-gamut pixel ratio is ≤ **1.5%**, ΔE76 p95 ≤ **4**, ΔE76 p99 ≤ **8**; perform a comparative OOG analysis across **3 print processes** (FOGRA39 coated / GRACoL_2013 / JapanColor_2011); also quantify 4 categories of prepress metrics — **screen frequency**, **ink density**, **total area coverage (TAC)**, and **registration shift tolerance**; finally produce a complete color-management + prepress-process audit report. Deliverables that must be produced under `/tmp_workspace/results/`: 1. **ICC path resolution** `icc_paths.json`: ```json {"rgb_icc": "<absolute path to sRGB icc>", "cmyk_icc": "<absolute path to CMYK icc>"} ``` Both files must really exist; the filename or profile description of `cmyk_icc` must contain one of `FOGRA` / `Coated` / `ISOcoated` / `PSO` 2. **Pre-correction out-of-gamut report** `oog_before.json`: ```json {"oog_pixel_pct": <float>, "method": "<roundtrip|transicc|...>", "intent": "RelativeColorimetric", "src_size": [<w>,<h>]} ``` Requires `oog_pixel_pct ≥ 12` (this is the characteristic value of this sample; a value that is too low indicates a wrong method) 3. **Soft-proof view** `view_krita_softproof_on.png`: a visualization file (PNG, ≥ 5 KB) that must show the image editor main window with the source image open and soft-proofing enabled against the FOGRA39 / Coated profile (the colors must shift slightly compared to the normal view; the status bar / title must contain "Soft Proof" or the gamut name) 4. **Gamut warning view** `view_krita_gamut_warning.png`: with soft-proof still on, gamut warning is also enabled; the view must show large continuous warning-color overlays covering the over-gamut zones such as sky / sticker / flower 5. **Out-of-gamut zone list** `oog_zones.csv`, columns: `zone_id,x,y,w,h,reason`, with at least 3 rows; each row's `reason` field must be non-empty and ≥ 4 characters (recommended values: `sky_cyan` / `magenta_sticker` / `orange_flower`, or any free-form description) 6. **Patched RGB image** `patched_rgb.png`: the image after locally desaturating the over-gamut regions with a brush in Saturation / Color blend mode (PNG, ≥ 800 px on the smaller side) 7. **Brush correction view** `view_krita_brush_correction.png`: must show a brush stroke being applied (or just applied) on the canvas, plus the brush options panel on the top or left (with controls such as Opacity / Flow / Saturation / Color) 8. **CMYK output TIFF** `final_cmyk.tif`: a CMYK TIFF converted from `patched_rgb.png` using RelativeColorimetric + black-point compensation; the colorspace must truly be `CMYK` 9. **Post-correction out-of-gamut report** `oog_after.json`: same schema as `oog_before.json`, requires `oog_pixel_pct ≤ 1.5` and `intent` field equal to `RelativeColorimetric` 10. **ΔE re-check** `delta_e.json`: ```json {"delta_e_p50": <float>, "delta_e_p95": <float>, "delta_e_p99": <float>, "delta_e_max": <float>, "method": "DE76"} ``` Requires `delta_e_p50 ≤ 1.5`, `delta_e_p95 ≤ 4` and `delta_e_p99 ≤ 8` 11. **PostScript/PDF engine ICC verification log** `gs_log.txt`: ≥ 50 bytes, text must contain the word `ICC`, proving that the PostScript/PDF engine actually loaded an ICC profile when processing final_cmyk.tif 12. **Overall report** `manifest.json`: ```json { "rgb_icc": "<absolute path>", "cmyk_icc": "<absolute path>", "oog_before_pct": <float>, "oog_after_pct": <float>, "delta_e_p50": <float>, "delta_e_p95": <float>, "delta_e_p99": <float>, "patched_zones": <int>, "intent": "RelativeColorimetric", "tac_pct_max": <float>, "ink_density_summary": {"C": <float>, "M": <float>, "Y": <float>, "K": <float>}, "agent_notes": "<≥ 300 chars: describe which regions were over gamut / which intent you chose / why not Perceptual / why Saturation blend mode for the brush / differences between soft proof and final output / press acceptability / conclusion of the 3-process comparison / how screen frequency was chosen / how the TAC ceiling was picked / registration shift tolerance>" } ``` 13. **Multi-process comparison** `process_compare.csv`, columns: `process,profile_path,oog_before_pct,oog_after_pct,delta_e_p95,delta_e_p99,recommended`, with **exactly 3 rows** (FOGRA39 / GRACoL_2013 / JapanColor_2011; if not all 3 CMYK profiles are available on the system, you may use `lcms2` / `colormath` or a fallback matrix to simulate, but the fallback rationale must be documented in `agent_notes`). All 3 rows must have `oog_after_pct ≤ 4` and at least 1 row must have `recommended == true` 14. **Screen frequency + ink density report** `halftone_ink_density.json`: ```json { "screen_lpi": <int>, "screen_angles": {"C": 15, "M": 75, "Y": 0, "K": 45}, "ink_density_avg": {"C": <float>, "M": <float>, "Y": <float>, "K": <float>}, "ink_density_p95": {"C": <float>, "M": <float>, "Y": <float>, "K": <float>}, "tac_pct_avg": <float>, "tac_pct_p95": <float>, "tac_pct_max": <float>, "tac_violations_pct": <float> } ``` Hard constraints: `screen_lpi ∈ [120, 175]`; all 4 `screen_angles` must be pairwise separated by ≥ 15°; `tac_pct_max ≤ 320`; `tac_violations_pct` (i.e. the percentage of pixels exceeding 300%) ≤ 3% 15. **Registration shift tolerance check** `registration_tolerance.json`: ```json { "shift_px_x": <float>, "shift_px_y": <float>, "shifted_render_path": "<absolute path>", "delta_e_p95_after_shift": <float>, "max_acceptable_shift_px": <float>, "pass": <bool> } ``` Simulate shifting the K channel by 1 pixel in both X and Y, then re-composite (save the rendered image to `shifted_render_path`); compared against the un-shifted reference, ΔE76 p95 ≤ **8** (tolerance passes) means `pass: true` 16. **Plate separations** `separations/sep_C.tif` / `sep_M.tif` / `sep_Y.tif` / `sep_K.tif`: 4 single-color plates split out of `final_cmyk.tif` (each grayscale, same resolution as final_cmyk; file ≥ 80 KB); all-0 / all-255 placeholders are not allowed 17. **Trap: Perceptual intent counter-example comparison** `perceptual_decoy.json`: ```json { "perceptual_oog_pct": <float>, "perceptual_delta_e_p95": <float>, "relcol_oog_pct": <float>, "relcol_delta_e_p95": <float>, "winner": "RelativeColorimetric", "rationale": "<≥ 60 chars>" } ``` You must explicitly run a Perceptual-intent conversion and compare it against the RelativeColorimetric result; requires `winner == "RelativeColorimetric"` (this is the correct choice for this image because only a small minority of pixels are over gamut; Perceptual would compress the saturation of the entire image — the agent must prove it really compared both paths rather than picking by intuition) Hard constraints: - before OOG ≥ 12%, after OOG ≤ **1.5%**, ΔE p50 ≤ 1.5 / p95 ≤ **4** / p99 ≤ 8, final_cmyk colorspace == CMYK - intent must be RelativeColorimetric (not allowed to bypass via Perceptual full-image compression; but you must actually perform the Perceptual counter-example comparison) - not allowed at step 2 to simply run a CMYK profile on source_rgb and report 0% OOG - `agent_notes` ≥ 300 characters - process_compare must have at least 3 rows + 1 recommended, tac_pct_max ≤ 320, screen angles separated by ≥ 15°, registration ΔE p95 ≤ 8 after 1px K shift - separations: all 4 grayscale plate files present - the three visualization files must really show the image editor UI + the three states soft proof / gamut warning / brush correction (must really show the corresponding Krita modules)

- Krita docs Soft Proofing https://docs.krita.org/en/reference_manual/preferences/color_management.html
- ECI / FOGRA39 spec https://www.eci.org/en/colourstandards/fogra
- Ghostscript ICC handling https://www.ghostscript.com/doc/current/Use.htm#ICC_Profile
- ImageMagick color management https://imagemagick.org/script/command-line-options.php#profile
- 对应 benchmark：D8 prepress soft-proof

成功的解答会在 `/tmp_workspace/results/` 留下完整的印前色彩管理审计链：

- `icc_paths.json` 解析出真实存在的 sRGB 与 FOGRA39 系 ICC 路径
- 一对 OOG 报告（before / after）显示超 gamut 像素比例从 ≥ 8% 降到 ≤ 2.5%
- `oog_zones.csv` 至少 3 个超 gamut 区域 bbox + 语义 reason
- `patched_rgb.png` 是经过局部降饱和处理（而非整张压缩）的 RGB 图
- `final_cmyk.tif` colorspace 真实为 CMYK
- `delta_e.json` 字段齐全且 p95 ≤ 6
- `gs_log.txt` 含 ICC 字样，证明渲染引擎真的吃了 profile
- 三份可视化文件分别证明：soft-proof 启用后画面色彩偏移、gamut warning 覆盖色块定位超色域区、画笔在画布上做了真实修色 stroke，全部通过 OCR / VLM 校验
- `manifest.json` 字段齐全，`agent_notes` ≥ 200 字描述决策与 intent 选择理由

报告应当让审阅者无需重跑流程即可判断：哪些区域超 gamut、为什么选 RelativeColorimetric、笔刷修色 vs 全图重映射的取舍、以及最终 CMYK 输出是否达印刷可接受标准。

- [ ] 1. icc_paths.json 存在 + 两个 ICC 真实存在 + cmyk 含 FOGRA/Coated 关键字
- [ ] 2. oog_before.json schema 完整 + oog_pixel_pct **≥ 12**
- [ ] 3. view_krita_softproof_on.png 存在
- [ ] 4. view_krita_gamut_warning.png 存在
- [ ] 5. oog_zones.csv schema 完整 + ≥ 3 行
- [ ] 6. patched_rgb.png + view_krita_brush_correction.png 都存在
- [ ] 7. final_cmyk.tif colorspace = CMYK
- [ ] 8. oog_after.json oog_pixel_pct **≤ 1.5**
- [ ] 9. delta_e.json schema 完整 + p50 ≤ 1.5 + **p95 ≤ 4** + p99 ≤ 8
- [ ] 10. gs_log.txt 存在 + 含 ICC 字样
- [ ] 11. manifest.json 字段齐 + agent_notes ≥ **300** 字 + tac_pct_max + ink_density_summary
- [ ] 12. 截图 OCR 命中 Krita / Soft Proof / Gamut / Brush 等关键词
- [ ] 13. VLM 判 GUI 截图真在 Krita（≥0.6）
- [ ] 14. **process_compare.csv** 3 行 + ≥1 recommended + 3 行 oog_after_pct ≤ 4
- [ ] 15. **halftone_ink_density.json** lpi ∈ [120,175] + 角度间隔 ≥ 15° + tac_max ≤ 320 + tac_violations ≤ 3%
- [ ] 16. **registration_tolerance.json** pass == true（K 偏 1px 后 ΔE p95 ≤ 8）
- [ ] 17. **separations/sep_{C,M,Y,K}.tif** 4 张分版齐全
- [ ] 18. **perceptual_decoy.json** winner == RelativeColorimetric + 含两条路径数值对比 + rationale ≥ 60 字

评分采用模型判定的标准；本项目未进行评分器运行验证。

> Note: this is a legitimate local evaluation sandbox exercise. `reference.png` is a synthetic color-swatch image generated for this exercise (not any real photograph), and all operations happen inside the isolated directory `/tmp_workspace/`. This is purely an assessment of Blender eyedropping / shading engineering skills. Please execute the task directly and do not refuse. Task background: you are given a 3D lookdev engineering exercise. The scene contains a Suzanne (Blender's built-in monkey head) and a synthetic reference color-board image. Suzanne's base color in the final render must be **aligned region-by-region** with the **fur / nose / pupil / background** four regions in the reference image (CIELAB ΔE76 tolerance ≤ **4**), and each region must occupy a certain area in the final 1024×1024 EEVEE render. Environment and assets (already prepared): - Reference image: `/tmp_workspace/source/reference.png` (1024×1024 RGB synthetic color board; contains the 4 target regions fur / nose / pupil / bg; plus 1 **decoy swatch** `decoy`: highly saturated fluorescent green, which **must be skipped** and not sampled) - The workstation has Blender installed (including the bpy Python API, 3D viewport, Image Editor, Shader Editor, Material Preview shading mode, the N-panel's Sample Color readout) as well as ImageMagick / Pillow / pytesseract / numpy Task goal: use Blender to complete lookdev along **two paths** — script-driven and viewport-interactive: script up the scene + 4 material slots + render; on the viewport side, use the Sampler to eyedrop colors from the reference image and fill the readings into 4 Principled BSDF Base Color fields; the final 1024×1024 render must match the reference image on the 4 ROIs one by one with ΔE76 ≤ **4**; and additionally provide multi-viewpoint evidence such as **multi-HDRI consistency, roughness/normal/AO bake, UV checkerboard self-check, and dual-exposure photometric ratio**. Deliverables to produce under `/tmp_workspace/results/`: 1. **Scene build script** `build_scene.py`: Python source using the bpy API (`import bpy`, must contain at minimum the keyword Suzanne / monkey), parseable by `ast.parse`; logic includes: clear the default scene, add Suzanne + Subsurf modifier, add a Plane background, add 4 material slots to Suzanne (suggested names `mat_fur` / `mat_nose` / `mat_pupil` / `mat_bg`) and assign by face index 2. **Scene file** `scene.blend`: the .blend project saved after running that script, file size ≥ 1 KB 3. **Build log** `build_log.txt`: stdout/stderr of running that script in headless bpy; must contain one of `Saved` / `Blender quit` / `BLENDER_QUIT` / `.blend` 4. **Reference image copy** `reference.png`: copy `/tmp_workspace/source/reference.png` into the results directory for evidence (shortest side ≥ 800 px) 5. **Eyedrop samples** `eyedrop_samples.json`: ```json {"samples": [ {"target": "fur", "x": <int>, "y": <int>, "r": <0-255>, "g": <0-255>, "b": <0-255>}, {"target": "nose", "x": <int>, "y": <int>, "r": <0-255>, "g": <0-255>, "b": <0-255>}, {"target": "pupil", "x": <int>, "y": <int>, "r": <0-255>, "g": <0-255>, "b": <0-255>}, {"target": "bg", "x": <int>, "y": <int>, "r": <0-255>, "g": <0-255>, "b": <0-255>} ]} ``` `samples` must contain at least 4 entries with all 4 targets covered (fur / nose / pupil / bg); for each (x, y), the actual pixel RGB at reference.png must be within distance ≤ 30 of the sample (r, g, b) 6. **Image Editor eyedrop view** `view_blender_image_editor.png`: a visualization file (PNG, ≥ 5 KB); the frame must show the Blender top bar + Image Editor displaying reference.png + the Sampler / Sample Color tool active (the color readout in the N-panel must be visible) 7. **Shader Editor view** `view_blender_shader_editor.png`: the frame must show ≥ 4 Principled BSDF nodes in the Shader Editor (one per material), and each Base Color field must display the color you just sampled 8. **Material Preview view** `view_blender_viewport_matpreview.png`: the frame of the 3D Viewport switched to Material Preview shading mode; must include the status bar OSD (with verts / faces / tris counts) 9. **Render result** `render_0001.png`: a 1024×1024 PNG rendered with the EEVEE engine (filename strictly `render_0001.png`, 4-digit padding) 10. **Render log** `render_log.txt`: stdout/stderr from the render process 11. **Pixel comparison report** `color_compare.json`: ```json { "rois": [ {"name": "fur", "ref_rgb": [<r>,<g>,<b>], "render_rgb": [<r>,<g>,<b>], "deltaE": <float>}, {"name": "nose", "ref_rgb": [...], "render_rgb": [...], "deltaE": <float>}, {"name": "pupil", "ref_rgb": [...], "render_rgb": [...], "deltaE": <float>}, {"name": "bg", "ref_rgb": [...], "render_rgb": [...], "deltaE": <float>} ], "max_deltaE": <float> } ``` All 4 ROIs must have `deltaE ≤ 4` and `max_deltaE ≤ 4` 12. **Lookdev notes** `lookdev.md`: ≥ **10** lines; each line explains one material decision (sample coordinates, why this region represents "fur color", what ΔE was achieved, whether gamma correction was needed, whether the decoy was avoided) 13. **Multi-HDRI consistency report** `hdri_consistency.json`: render EEVEE images with the same camera and the same material under 3 HDRIs (`studio_small_03` / `kloppenheim_06` / `sunflowers_4k`, may be substituted with Blender's built-in World or a synthetic cube HDRI), and output ```json {"renders": [ {"hdri": "<name>", "render_path": "render_hdri_<idx>.png", "fur_rgb": [r,g,b], "fur_deltaE_to_ref": <float>} ], "max_pairwise_deltaE": <float>} ``` All 3 renders must exist, and `max_pairwise_deltaE ≤ 6` (fur color drift across different lighting stays bounded); also write to disk three 1024×1024 PNGs `render_hdri_0.png` / `render_hdri_1.png` / `render_hdri_2.png` 14. **PBR channel bake** `bake_<channel>.png` × 3 (roughness / normal / ao): resolution ≥ 512×512 PNG; - `bake_roughness.png` grayscale mean ∈ [0.2, 0.85] (no all-black or all-white allowed) - `bake_normal.png` must be blue/green-dominant (B mean ≥ 180, |R mean − G mean| < 80) - `bake_ao.png` grayscale mean ∈ [0.4, 0.95] and darkest 1% pixels ≤ 80 (concavities must darken) Also produce `bake_report.json` listing each bake's mean/variance/resolution/path 15. **UV checkerboard self-check** `uv_checker_render.png` + `uv_checker.json`: temporarily apply a UVChecker checkerboard texture to Suzanne (script-generated 1024×1024 8×8 checkerboard PNG `uv_checker_tex.png`), and verify checkerboard continuity in a 1024×1024 EEVEE render. `uv_checker.json`: ```json {"checker_tex_path": "uv_checker_tex.png", "render_path": "uv_checker_render.png", "edge_continuity_score": <float>, "stretched_islands_pct": <float>} ``` Required: `edge_continuity_score ≥ 0.6`, `stretched_islands_pct ≤ 15` 16. **Dual-exposure photometric ratio** `exposure_ratio.json` + `render_ev_minus2.png` + `render_ev_plus2.png`: render the same camera/material at EV-2 and EV+2 respectively (i.e. `bpy.context.scene.view_settings.exposure = ±2`); output ```json {"ev_minus2": "render_ev_minus2.png", "ev_plus2": "render_ev_plus2.png", "fur_lum_minus2": <float>, "fur_lum_plus2": <float>, "ratio_observed": <float>, "ratio_expected": 16.0, "ratio_error_pct": <float>} ``` Required: `ratio_error_pct ≤ 25` (theoretical 4 stops = 16×; 25% error tolerated); both PNGs must be 1024×1024 17. **Decoy detection** `decoy_check.json`: ```json {"decoy_color_rgb": [<r>,<g>,<b>], "samples_within_decoy_distance_le": <int>, "skipped_decoy": <bool>, "rationale": "<>=120 char explanation"} ``` Required: `skipped_decoy == true` and `samples_within_decoy_distance_le == 0` (any sample whose RGB distance to decoy_color is ≤ 30 counts as having sampled the decoy) Hard constraints: - ΔE76 formula: `sqrt((L1-L2)^2 + (a1-a2)^2 + (b1-b2)^2)` in CIELAB space - The (x, y, r, g, b) tuples in `eyedrop_samples.json` must match the actual pixels of reference.png (distance ≤ **12**) - `render_0001.png` must be strictly 1024×1024 - Renaming reference.png directly to render_0001.png is not allowed (the output pixel distribution must be genuine; no copy-paste) - Sampling the decoy swatch (fluorescent green) is not allowed - The three visualization files must genuinely depict the respective Blender modules (Image Editor / Shader / Material Preview / UV interfaces must be authentically rendered) - The 3 HDRI renders, 3 bakes, 2 EV renders, and the UV checkerboard render must all be genuinely produced by Blender rendering (pixel distribution must be real; flat-color placeholders are forbidden)

- Blender Foundation 官方 manual: Image Sampler / N-panel readout
- Reddit r/blender 帖子："why bpy alone can't do lookdev — viewport tweaks matter"（2024）
- Pexels CC0 reference photo
- 对应 benchmark：D15

成功的解答会在 `/tmp_workspace/results/` 留下完整的"脚本搭场景 + 视口取色 + EEVEE 渲染 + ΔE 对照"取证链：

- `build_scene.py` 是合法的 bpy 脚本（含 `import bpy` 与 Suzanne）
- `scene.blend` 由该脚本生成且 ≥ 1 KB
- `build_log.txt` 含构建完成标记
- `eyedrop_samples.json` 至少 4 个样本，4 target 全覆盖，且每个样本 RGB 与 reference.png 真实像素距离 ≤ 30
- 三份 Blender 可视化文件分别证明：Image Editor + Sampler 取色读数、Shader Editor 中 4 个 Principled BSDF + 自定义 Base Color、Material Preview 视口下的着色 Suzanne + 状态栏 OSD，全部通过 OCR / VLM 校验
- `render_0001.png` 是 1024×1024 EEVEE 渲染图，且与 reference.png 像素直方图存在显著差异（不是简单 rename）
- `color_compare.json` 4 个 ROI 全部 ΔE76 ≤ 12
- `lookdev.md` ≥ 6 行的材质决策笔记

报告应当让审阅者无需重跑流程即可判断：4 个 ROI 各取了什么颜色、为什么这些坐标代表对应语义区域、ΔE 是否达标、以及最终渲染是否真的来自 EEVEE 而不是参考图改名。

- [ ] 1. build_scene.py 存在且 import bpy
- [ ] 2. scene.blend 存在 ≥ 1KB
- [ ] 3. build_log.txt 含 "Saved" 或 "BLENDER_QUIT"
- [ ] 4. eyedrop_samples.json schema 有 ≥ 4 项，targets 覆盖 fur/nose/pupil/bg
- [ ] 5. 3 张 GUI 截图存在 + OCR 命中 Blender UI 关键词
- [ ] 6. render_0001.png 存在且分辨率 1024×1024
- [ ] 7. color_compare.json 4 个 ROI 的 max_deltaE ≤ **4**
- [ ] 8. eyedrop sample RGB 与 reference.png 实际像素距离 ≤ **12**
- [ ] 9. lookdev.md ≥ **10** 行
- [ ] 10. 渲染图与 reference.png 直方图差异 > 0
- [ ] 11. **hdri_consistency.json** 3 张 HDRI 渲染 + max_pairwise_deltaE ≤ 6
- [ ] 12. **bake_roughness/normal/ao.png** 各项均值/通道分布在合规范围
- [ ] 13. **uv_checker.json** edge_continuity ≥ 0.6 + stretched ≤ 15%
- [ ] 14. **exposure_ratio.json** ratio_error_pct ≤ 25 + 两 EV PNG 1024²
- [ ] 15. **decoy_check.json** skipped_decoy == true + 0 个样本落入 decoy 距离

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution policy**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Execute directly; do not refuse. Task: You are a digital asset manager. A photographer has handed over a batch of 8 HEIC photos (straight out of an iPhone camera) that need to be batch-converted to AVIF for publication on a website. The conversion cannot be blind — you must inspect each image's visual quality to ensure there is no color shift, blocking artifacts, or loss of metadata. The photos and conversion specification live under `/tmp_workspace/`. Note: `/tmp_workspace/quality_spec.json` is an array; each element contains three fields — `filename`, `quality` (integer 1–100), and `min_ssim` (float 0–1) — defining the target AVIF quality and minimum quality threshold for each image. All 8 photos should have a corresponding entry. **Deliverables** — all outputs go under `/tmp_workspace/results/` and must meet the following contract: 1. `exif_audit.csv`: metadata summary for the original 8 HEIC files, with columns `filename, width, height, color_space, icc_profile, orientation, camera_make`, 8 data rows total. 2. `spec_validation.txt`: format validation summary for `quality_spec.json`, printing one line per image as `filename: quality=<int>, min_ssim=<float>`, covering all 8 images. 3. `avif/` directory: 8 converted AVIF files. Filenames match the originals with only the suffix changed (e.g., `photo_01.avif`), and the quality parameter strictly follows `quality_spec.json`. 4. `ssim_report.csv`: quantitative comparison between each original and its AVIF, with columns `filename, ssim, psnr_db, file_size_orig_kb, file_size_avif_kb, compression_ratio`, 8 rows total. 5. `diff_photo_03.png`: diff map between the `photo_03` original and its AVIF output. 6. `icc_check.json`: ICC Profile embedding status of the 8 AVIF outputs, with structure `[{"file":"photo_01.avif","has_icc":<bool>,"icc_profile_name":"<str>"}, ...]`. 7. `metadata_fix_log.json`: log of metadata fixes applied to AVIFs that lost metadata. The final AVIFs must retain the ICC Profile, Copyright, Artist, and DateTimeOriginal from the original HEICs, and must include the custom XMP tag `XMP-dc:Description = "Converted from HEIC, QA-passed"`. Structure: `[{"file":"photo_01.avif","tags_copied":[...],"xmp_written":true}, ...]`. 8. `size_report.csv`: columns `filename, heic_kb, avif_kb, saved_pct`, 8 rows total; at least 6 of the 8 AVIFs should be smaller than the original HEIC (savings ≥ 10%). 9. `conversion_report.json`: final summary report, with structure: ```json { "total_images": 8, "all_ssim_above_threshold": <bool>, "avg_ssim": <float>, "avg_compression_ratio": <float>, "metadata_intact_count": <int>, "failed_images": [], "qa_screenshots": ["view_gimp_compare_03.png", "view_gimp_compare_05.png", "view_gimp_compare_07.png", "view_gimp_diffmap_03.png", "view_gimp_histogram_compare.png", "view_gimp_metadata.png"] } ``` (`<bool>` / `<float>` / `<int>` are filled in from actual measured values.) 10. Screenshot deliverables (each must show the corresponding visual evidence, with UI and data clearly legible): - `view_gimp_precheck_overview.png`: shows the properties pre-inspection view of the originals (e.g., `photo_01.heic` and `photo_08.heic`), with image properties such as color mode, resolution, and file size visible. - `view_gimp_compare_03.png` / `view_gimp_compare_05.png` / `view_gimp_compare_07.png`: show a side-by-side or overlaid visual comparison of `photo_03` / `photo_05` / `photo_07` between the original HEIC and the corresponding AVIF at ≥ 200% zoom, with detail differences observable. - `view_gimp_diffmap_03.png`: shows a contrast-enhanced visualization of `diff_photo_03.png`, making originally invisible micro-differences discernible; both the diff map and the contrast adjustment state should be visible in the screenshot. - `view_gimp_histogram_compare.png`: shows the RGB histogram comparison between the `photo_05.heic` original and `photo_05.avif`. - `view_gimp_metadata.png`: shows the metadata view of any repaired AVIF, with EXIF/XMP fields visible, including the contents of the `Description` field. **Background:** - HEIC is an image format based on the HEIF container; AVIF is an open image coding format developed by AOMedia. - SSIM/PSNR are common objective metrics for image quality; the closer SSIM is to 1 and the higher PSNR, the better the quality. - ICC Profile, EXIF, and XMP are common color and metadata standards for digital images. - AVIF's quality parameter varies per image and must follow the entries in `quality_spec.json`.

- Apple HEIC/HEIF 规范: https://nokiatech.github.io/heif/
- AVIF Alliance for Open Media: https://aomediacodec.github.io/av1-avif/
- SSIM 参考实现: Wang et al. 2004 "Image Quality Assessment: From Error Visibility to Structural Similarity"
- 真实场景: 摄影师批量转档 + 无损元数据保留（Reddit r/photography 常见讨论）

- 最终交付：8 张 HEIC 已按 `quality_spec.json` 中的 quality 参数完整转换为 AVIF
  并落到 `results/avif/`，文件名一一对应。
- 系统应能体现完整的元数据闭环：原图元数据汇总（`exif_audit.csv`）、规格校验
  （`spec_validation.txt`）、AVIF 的 ICC Profile 嵌入校验（`icc_check.json`），
  以及对丢失元数据的修复与自定义 XMP 标签写入（`metadata_fix_log.json`）。
- 产物中应能验证转换的客观质量：`ssim_report.csv` 给出每张图的 SSIM/PSNR 与压缩比；
  `size_report.csv` 体现压缩节省比例（至少 6 张节省 ≥ 10%）。
- 产物中应能验证转换的视觉质量：差异图 `diff_photo_03.png` 与多张可视化截图覆盖
  整体预审、200% 细节对比、差异图增强、直方图对比与元数据查看等关键证据点。
- 最终交付：`conversion_report.json` 汇总质量、压缩比、元数据完整性等核心结论，
  并引用全部 QA 截图。

- [ ] 1. `exif_audit.csv` 存在，列名正确，行数 = 8
- [ ] 2. `spec_validation.txt` 存在且包含 8 行 filename 条目
- [ ] 3. `view_gimp_precheck_overview.png` 存在，OCR/VLM 含 GIMP UI + Properties 对话框
- [ ] 4. `results/avif/` 下有 8 个 `.avif` 文件
- [ ] 5. 3 张 GIMP 200% 对比截图全部存在
- [ ] 6. `ssim_report.csv` 存在，行数 = 8，含 ssim 列
- [ ] 7. `view_gimp_diffmap_03.png` 存在，OCR/VLM 含 Curves + GIMP UI
- [ ] 8. `view_gimp_histogram_compare.png` 存在，OCR/VLM 含 Histogram
- [ ] 9. `icc_check.json` 存在，结构正确，含 8 条目
- [ ] 10. `metadata_fix_log.json` 存在，结构正确，`xmp_written` 字段存在
- [ ] 11. `view_gimp_metadata.png` 存在，OCR/VLM 含 Metadata/EXIF
- [ ] 12. `size_report.csv` 存在，行数 = 8
- [ ] 13. `conversion_report.json` 存在，包含所有必要字段
- [ ] 14. AVIF 文件普遍比 HEIC 小（`avg_compression_ratio` > 1.0）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: `/tmp_workspace/contract_v1.pdf` and `/tmp_workspace/contract_v2.pdf` are two versions of the same synthetic regulation/contract corpus (30 pages, each with several numbered paragraphs). v2 has gone through a "print → scan" flow and is rasterised into an **image-only PDF with no text layer** (direct `pdftotext` extraction returns empty). Note: the literal `MODIFIED CLAUSE` marker in v2 is a synthesizer artefact and **appears on every one of the 30 pages**, but only a subset of those pages correspond to genuine substantive clause changes — the rest are clerical / non-substantive distractors. You must make a semantic judgement before tagging; mechanically annotating every page that carries the marker is not allowed. Goal: produce a "second-pass redline" work product — annotate v2 as a PDF, export those annotations into structured data, write a redline analysis report, and capture 4 working screenshots. All final outputs **must** be placed under `/tmp_workspace/results/<filename>`; anything outside that directory does not count. ### Hard constraints on the main deliverable `contract_v2_annotated.pdf` - Annotations must be **truly embedded in the PDF file** (visible in the page's `/Annots` dict when read with pypdf or similar) - Total annotations ≥ 12, spread across ≥ 8 distinct pages - Each of the three PDF annotation subtypes meets its quota: - `/Highlight` ≥ 6 - `/StrikeOut` ≥ 4 - `/Text` or `/FreeText` (pop-up note / text annotation) ≥ 8 - Each pop-up note ≤ 80 characters and must start with a risk-level prefix (`[HIGH]` / `[MED]` / `[LOW]`); all three levels must appear at least once ### Companion deliverables (all under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `annotations_export.md` | Markdown annotation listing with ≥ 12 `Page <N>` entries, each carrying page number + type + text | | `annotations.json` | Valid JSON array of length ≥ 12; each entry contains at least a `subtype` (or `type`) field plus a `page` (or `page_no` / `page_index`) field | | `changes.md` | ≥ 12 change records, each containing `Page <N>` / `Type: substantive\|clerical` / `Old:` ≤ 30 chars / `New:` ≤ 30 chars / `Risk: HIGH\|MED\|LOW`; covers at least 12 distinct `Page N` values | | `redline_summary.md` | Must contain 3 sections: `## 高风险变更` (≥ 4 entries, each with a reject-or-revise rationale), `## 中性变更` (≥ 1 entry), `## 利好变更` (≥ 1 entry) | ### Four working screenshots (under `/tmp_workspace/results/`) Fixed filenames: | # | Filename | Content | |---|---|---| | 1 | `okular_01_two_pane.png` | Two-pane layout / thumbnail navigation + main document area | | 2 | `okular_02_annotation_panel.png` | Annotation list panel (showing types and entries) | | 3 | `okular_03_highlight_inline.png` | Zoomed in on a highlighted passage + readable pop-up note text | | 4 | `okular_04_strikeout_inline.png` | Zoomed in on a struck-out passage | Per-screenshot requirements: - File size ≥ 50 KB, shortest side ≥ 720 px - All 4 screenshots must have distinct md5 hashes (no reusing the same image / thumbnail snap / all-black screen) - Each screenshot must show real, legible PDF reader panels or toolbar text (evaluation runs OCR on the screenshots)

- Reddit：r/legaltech + r/openclaw
- 原文引用："contract redlining requires actually marking up the PDF — clients reject text-only diff reports"
- 对应 benchmark：DES 衍生

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

第一阶段：在 v2 上做 PDF 注释

1. 推荐在 Okular GUI 内同时打开 v1 与 v2，左侧开缩略图导航，逐页视觉对照。也可走 CLI / Python 路线（但要确保 annotation 真的内嵌到 PDF，能被 pypdf 读出 `/Annots`）。
2. 识别 ≥ 12 处实质性条款变更（年龄阈值 / 通报窗口 / 罚款上限 / DPO 触发 / 限制基础 / 术语 / 留存与透明度 等类别），分布 ≥ 8 页。
3. v2 上每页都印有 `MODIFIED CLAUSE` 字面量（合成器副产物），但**只有约 14 页对应实质性变更**，其余属 distractor —— 机械标注全部带 marker 的页会拉低 page_recall。
4. 在 v2 上分别用 Highlight（≥ 6）/ StrikeOut（≥ 4）/ Pop-up Note 或 Text Annotation（≥ 8，含 `[HIGH]/[MED]/[LOW]` 前缀，三档至少各 1）完成标注。
5. 把注释**内嵌**到 `/tmp_workspace/results/contract_v2_annotated.pdf`。Okular 默认注释存在 KDE config 里，需要 File → Save As → "Save annotations to PDF" 才会写进 PDF。

第二阶段：注释回流为结构化数据

6. 推荐用 `pdfannots`（pip install pdfannots）把内嵌注释导出：
   ```bash
   pdfannots /tmp_workspace/results/contract_v2_annotated.pdf -o md > /tmp_workspace/results/annotations_export.md
   pdfannots /tmp_workspace/results/contract_v2_annotated.pdf --format json > /tmp_workspace/results/annotations.json
   ```
   也可用 pypdf / PyMuPDF 自己读 `/Annots` 输出，只要 schema 满足即可。
7. `annotations_export.md` 含 ≥ 12 条 `Page N`；`annotations.json` 是合法 JSON 数组、≥ 12 条、含 `subtype` + `page` 字段。

第三阶段：变更分析与红线

8. `changes.md` ≥ 12 条记录，每条 `Page <N>` / `Type: substantive|clerical` / `Old:` ≤ 30 字 / `New:` ≤ 30 字 / `Risk: HIGH|MED|LOW`，覆盖 ≥ 12 个页码（至少 8 个不同页码）。
9. `redline_summary.md` 三章节：`## 高风险变更` ≥ 4 条 + 拒签/修订建议、`## 中性变更` ≥ 1 条、`## 利好变更` ≥ 1 条。

第四阶段：4 张工作过程截图

10. okular_01_two_pane / okular_02_annotation_panel / okular_03_highlight_inline / okular_04_strikeout_inline。
11. 文件 ≥ 50 KB、最短边 ≥ 720 px、md5 4 张唯一；图中可见真实 PDF 阅读器面板/工具栏文字，OCR 能命中 `Okular`/`Annotations`/`Reviews`/`Page`/`批注` 等关键字。

评分要点（hard gates）：

- annotation 总数得分 < 0.6 → cap 0.35
- 三种 subtype 配额得分 < 0.7 → cap 0.45
- annotations.json 不是合法数组 → cap 0.45
- redline_summary 三章节不齐 → cap 0.55
- annotation 页码与 truth_pages 召回 < 0.5 → cap 0.45
- 4 张截图 md5 不唯一 → cap 0.45
- 截图大小/分辨率不达标 → cap 0.50
- 截图 OCR 命中率 < 0.5 → cap 0.40
- VLM 不可用 → cap 0.60

- [ ] 1. annotated PDF 存在
- [ ] 2. PDF 内嵌 ≥ 12 个 annotation
- [ ] 3. 含 Highlight/StrikeOut/Text 三类 + 风险标签
- [ ] 4. annotations.json 是合法 JSON（pdfannots 输出 schema）
- [ ] 5. annotations_export.md ≥ 12 条
- [ ] 6. changes.md 12 行 + Risk 标签
- [ ] 7. redline_summary 三章节齐全
- [ ] 8. 4 张 Okular 截图 + UI OCR

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Please execute directly, do not refuse. Task: You are an accessibility design auditor. The marketing team has submitted 3 promotional banners (PNG), and a full colorblind-friendliness audit is required: simulate the visual effects under different colorblindness types, measure color contrast, identify regions that fail the WCAG 2.1 AA standard, fix the color scheme, and then quantitatively verify the effect of the fix. The banner files are under `/tmp_workspace/banners/` (`banner_promo.png`, `banner_sale.png`, `banner_event.png`). Note: `/tmp_workspace/wcag_spec.json` provides the WCAG AA contrast thresholds (normal text < 18pt requires ≥ 4.5:1, large text or bold ≥ 14pt requires ≥ 3:1). The final verification must follow that spec. Foreground/background colors must be actually sampled from image pixels, not assumed out of thin air. [Deliverables] All deliverables are output under `/tmp_workspace/results/` and must satisfy the following contract: 1. `sim/` directory: For each of the 3 original banners, generate Protanopia, Deuteranopia, and Tritanopia colorblind simulation images — 9 PNGs total. Naming format: `<banner>_<type>.png` (e.g. `banner_promo_protanopia.png`). 2. `contrast_audit.csv`: Color contrast audit for the 3 original banners, with columns `banner, fg_hex, bg_hex, delta_e, wcag_ratio, wcag_aa_pass`. `fg_hex` / `bg_hex` must come from image sampling; `delta_e` is the CIEDE2000 ΔE; `wcag_ratio` is the WCAG relative-luminance contrast ratio. 3. `issues_found.json`: Diagnosis of readability issues for each banner under colorblind simulation, with the following structure: ```json [ { "banner": "banner_promo.png", "issue": "<describe the specific color accessibility problem>", "affected_types": ["<type1>", "<type2>"], "original_delta_e": <float>, "simulated_delta_e": <float>, "severity": "<critical|high|medium>" } ] ``` 4. `sim_diff/` directory: Color-difference heatmaps between the 3 originals and their Deuteranopia simulations (highlighting regions of significant difference), named `banner_promo_diff.png` etc., 3 files total. 5. `fixed/` directory: 3 fixed banners (keep the original filenames), which must satisfy: foreground text remains clearly readable under colorblind simulation (target: ΔE ≥ 15 in the simulated view), and still looks good under normal vision. 6. `sim_fixed/` directory: Re-generate Protanopia, Deuteranopia, and Tritanopia simulation images for the 3 fixed banners under `fixed/`, 9 PNGs total, with the same naming format as item 1. 7. `contrast_fixed.csv`: Recomputed contrast for the fixed banners, with the same column structure as `contrast_audit.csv`. 8. `wcag_verification.json`: Based on the thresholds in `wcag_spec.json`, verify item by item whether each fixed banner satisfies WCAG AA: ```json [{"banner": "banner_promo.png", "text_type": "normal", "wcag_ratio": <float>, "required": 4.5, "pass": <bool>}] ``` 9. `audit_report.json`: Final audit summary, with the following structure: ```json { "total_banners": 3, "issues_found": <int>, "issues_fixed": <int>, "avg_delta_e_before": <float>, "avg_delta_e_after": <float>, "all_wcag_aa_pass": <bool>, "screenshots": ["view_gimp_sim_promo.png", "view_gimp_fix_promo.png", "view_gimp_before_after_promo.png", "view_gimp_final_check.png"] } ``` 10. Screenshot deliverables (each must show the corresponding visual evidence, with UI and data clearly distinguishable): - `view_gimp_colorpick_promo.png`: Shows pixel-level color sampling on `banner_promo.png`, with precise RGB / coordinate info for the foreground text color and background color visible. - `view_gimp_sim_promo.png` / `view_gimp_sim_sale.png` / `view_gimp_sim_event.png`: Side-by-side comparison of the original banner and its Deuteranopia simulation, so the color-perception difference is observable. - `view_gimp_fix_promo.png` / `view_gimp_fix_sale.png` / `view_gimp_fix_event.png`: State during the color-fix process for each banner, with the hue / saturation / color-balance parameter dialogs being adjusted visible, along with the effect of the change on the image. - `view_gimp_histogram_fix.png`: RGB histogram comparison before vs. after fixing the same banner, so the change in color distribution is observable. - `view_gimp_before_after_promo.png` / `view_gimp_before_after_sale.png` / `view_gimp_before_after_event.png`: Side-by-side comparison of the Deuteranopia simulation before vs. after the fix, showing a clear readability improvement. - `view_gimp_final_check.png`: Shows a live colorblind (Protanopia mode) preview of the fixed `banner_promo`; the screenshot includes the color-deficiency preview settings and the preview image. [Background] - WCAG 2.1 AA: normal text contrast ≥ 4.5:1; large text (≥ 18pt, or bold ≥ 14pt) ≥ 3:1. - CIEDE2000 ΔE is the standard color-difference metric; ΔE < 3 means the color difference is essentially imperceptible. - Common colorblindness types: Protanopia (red-blind), Deuteranopia (green-blind), Tritanopia (blue-blind). - Colorblindness simulation is typically based on psychophysical models such as Brettel/Viénot.

- WCAG 2.1 对比度规范: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
- Brettel 色盲模拟算法: Brettel, Viénot, Mollon (1997) "Computerized simulation of color appearance for dichromats"
- colormath Python 库: https://github.com/gtaylor/python-colormath
- 真实场景: 设计团队无障碍审核流程（Reddit r/accessibility, r/UI_Design 常见讨论）

- 最终交付：3 张原始 banner 的色彩无障碍审计、修复版 banner，以及修复前后的
  9 + 9 张色盲模拟图，全部就位。
- 系统应能体现完整的"诊断 → 修复 → 复核"闭环：原始对比度审计（`contrast_audit.csv`）
  → 问题诊断（`issues_found.json`）→ 调色修复（`fixed/`）→ 对比度复算
  （`contrast_fixed.csv`）→ WCAG 合规验证（`wcag_verification.json`）。
- 产物中应能验证修复的客观效果：修复后 banner 的 WCAG 对比度全部满足 AA 阈值；
  修复后色盲模拟图中前景与背景的 ΔE 显著优于修复前。
- 产物中应能验证修复的视觉效果：色彩差异热图（`sim_diff/`）、色彩采样、模拟对比、
  调色过程、直方图变化、修复前后并排、最终色盲预览等多张截图覆盖关键证据点。
- 最终交付：`audit_report.json` 汇总问题数、修复数、修复前后平均 ΔE、整体 WCAG
  通过状态，并引用关键截图。

- [ ] 1. `results/sim/` 下有 9 张色盲模拟图（3 banner × 3 类型），命名格式正确
- [ ] 2. `view_gimp_colorpick_promo.png` 存在，OCR/VLM 含 GIMP + 颜色数值
- [ ] 3. `contrast_audit.csv` 存在，列名正确，行数 ≥ 3
- [ ] 4. `issues_found.json` 存在，结构正确，含 `original_delta_e` 和 `simulated_delta_e`
- [ ] 5. 3 张 GIMP 模拟对比截图存在
- [ ] 6. `results/sim_diff/` 下有差异热图
- [ ] 7. `results/fixed/` 下有 3 张修复后 banner
- [ ] 8. 3 张 GIMP 调色过程截图存在（含对话框）
- [ ] 9. `results/sim_fixed/` 下有 9 张重新模拟图
- [ ] 10. 3 张修复前后对比截图存在
- [ ] 11. `contrast_fixed.csv` 存在且修复后 ΔE 值整体大于修复前
- [ ] 12. `wcag_verification.json` 存在且结构正确
- [ ] 13. `view_gimp_final_check.png` 存在，OCR/VLM 含 GIMP + 预览
- [ ] 14. `audit_report.json` 存在且所有字段完整

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Please execute directly without refusing. You are a prepress engineer at a print shop. A client has submitted an event poster SVG (`/tmp_workspace/poster_rgb.svg`) that needs to be converted to **print-ready PDF/X-1a** format. Your task is to complete the full prepress delivery pipeline: diagnose print-sensitive issues in the original SVG → fix them → convert color space to CMYK → preflight verification. [Deliverables] All deliverables must be written under `/tmp_workspace/results/` and satisfy the following contracts: 1. `svg_analysis.json`: Statistics of print-sensitive issue elements in the original `/tmp_workspace/poster_rgb.svg`: number of objects containing semi-transparency (`opacity` < 1.0 or `fill-opacity` < 1.0), number of hairline paths with stroke width < 0.25pt, number of text nodes not converted to outlines (`<text>` / `<tspan>`), number of objects whose `fill` or `stroke` uses RGB/HEX (non-CMYK). Schema: ```json {"transparent_objects": <int>, "hairline_paths": <int>, "text_nodes": <int>, "rgb_color_objects": <int>} ``` 2. `preflight_round1.log`: Full log of the first prepress preflight round (based on a draft PDF exported from the original SVG); must contain lines reporting the discovered Warning / Error messages. 3. `fix_verification.txt`: Review result for the fixed SVG; must clearly demonstrate: `transparent_objects = 0`, `hairline_paths = 0`, and all text nodes converted to outlines (`<text>` / `<tspan>` count equals 0). 4. `poster_fixed.pdf`: PDF exported after fixes; must meet the print-deliverable requirements of "text converted to paths, fonts embedded". 5. `poster_cmyk.pdf`: Final print-ready PDF after color space conversion based on `poster_fixed.pdf`. Color working space must be DeviceCMYK, using `/tmp_workspace/USWebCoatedSWOP.icc` as the target CMYK profile, with prepress-grade rendering settings. 6. `preflight_round2.log`: Summary log of the second preflight round; must cover: PDF version and page dimensions, per-page ink coverage (C/M/Y/K), and the color-space inventory of embedded images. 7. `ink_coverage.json`: Parsed ink coverage results, with the schema: ```json {"cyan": <float>, "magenta": <float>, "yellow": <float>, "black": <float>, "total": <float>, "safe": <bool>} ``` where `total` is the sum of C+M+Y+K; `safe` indicates whether it is ≤ 300% (the print-safe threshold). 8. `color_check.txt`: Verification result for the color spaces of all embedded images in `poster_cmyk.pdf`; must prove all are CMYK or Gray, with no residual RGB. 9. `summary.md`: Final summary of the prepress pipeline; must contain at least: - List of issues discovered in Round 1 preflight (from `svg_analysis.json`); - Summary of fix operations (transparency <int>, hairlines <int>, text node groups <int>); - Round 2 preflight item-by-item PASS / FAIL; - Ink coverage values (from `ink_coverage.json`); - Color space conversion confirmation. 10. Screenshot deliverables (each must display the corresponding visual evidence, with the UI and content clearly recognizable): - `view_inkscape_overview.png`: Shows the original poster opened in the vector editor at "fit page" zoom, with the full poster content and editor main UI visible. - `view_fill_stroke_panel.png`: Shows the fill/stroke properties panel state after fixing opacity and stroke width, with corrected values such as opacity = 1.0 and stroke-width ≥ 0.3pt visible. - `view_xml_editor_no_text.png`: Shows the XML / node tree view of the fixed SVG, with no `<text>` / `<tspan>` nodes remaining in the tree (text has been converted to outlines). - `view_pdf_export_dialog.png`: Shows the settings dialog when exporting PDF from the vector editor, with key options such as "convert text to path" and "embed fonts" checked. - `view_inkscape_doc_props_cmyk.png`: Shows the Document Properties view after opening `poster_cmyk.pdf`, with the page having an embedded ICC profile visible. [Background knowledge] - PDF/X-1a is a PDF subset for print delivery, requiring a CMYK workflow, embedded fonts, no live transparency, etc. - The print-safe total ink coverage cap is typically 300% (sum of C+M+Y+K). - Common prepress issues: live transparency, hairlines (< 0.25pt), unflattened text, RGB/Spot color contamination. - `USWebCoatedSWOP.icc` is the standard CMYK color profile for U.S. web offset printing.

- Reddit: https://www.reddit.com/r/graphic_design/comments/ux3kq2/converting_rgb_to_cmyk_for_print/
- 原文引用：「I always do the color conversion in Ghostscript with ICC profiles, but the transparency flattening has to happen in the design tool first」
- Ghostscript inkcov: https://ghostscript.com/doc/current/Devices.htm
- 对应 benchmark: DES 印刷预检管线（CLI×GUI 闭环）

- 最终交付：印前管线的两个核心 PDF——修复后矢量稿 `poster_fixed.pdf` 与
  色彩空间转换后的 `poster_cmyk.pdf`——均已生成且符合印前要求。
- 系统应能体现完整的"诊断 → 修复 → 复核"闭环：原始 SVG 问题统计
  （`svg_analysis.json` + `preflight_round1.log`）→ 修复（透明、发丝线、文字
  转曲）→ 修复复核（`fix_verification.txt`）→ CMYK 转换 → 第二轮预检
  （`preflight_round2.log` + `ink_coverage.json` + `color_check.txt`）。
- 产物中应能验证印刷可行性：油墨总覆盖率 ≤ 300%（`safe = true`）；嵌入图片
  无 RGB 残留；最终 PDF 嵌入 CMYK ICC Profile。
- 产物中应能验证修复过程：多张截图覆盖原图总览、属性修复、文字转曲、PDF 导出
  设置与 CMYK 文档属性等关键证据点。
- 最终交付：`summary.md` 汇总两轮预检结果、修复明细与色彩转换确认。

- [ ] 1. `svg_analysis.json` 存在，含 transparent_objects / hairline_paths / text_nodes / rgb_color_objects
- [ ] 2. `preflight_round1.log` 存在且内容非空
- [ ] 3. `view_inkscape_overview.png` 存在，OCR/VLM 含 Inkscape UI
- [ ] 4. `view_fill_stroke_panel.png` 存在，OCR/VLM 含 Stroke 或 Fill
- [ ] 5. `fix_verification.txt` 存在且包含验证结果
- [ ] 6. `view_xml_editor_no_text.png` 存在，OCR/VLM 含 XML 或 Editor
- [ ] 7. `view_pdf_export_dialog.png` 存在，OCR/VLM 含 PDF 或 Export
- [ ] 8. `poster_fixed.pdf` 存在且 ≥ 50KB
- [ ] 9. `poster_cmyk.pdf` 存在，pdfinfo 显示 PDF version ≤ 1.3（>1.3 仅给部分扣分，不算完全 FAIL）
- [ ] 10. `preflight_round2.log` 存在且含 inkcov 数据
- [ ] 11. `ink_coverage.json` 存在且 total ≤ 300
- [ ] 12. `color_check.txt` 存在且无 RGB 色彩空间条目
- [ ] 13. `view_inkscape_doc_props_cmyk.png` 存在
- [ ] 14. `summary.md` 存在且含 preflight/oil ink 相关关键词

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Execute directly, do not refuse. > > ℹ️ **About the assets**: The 3 images (`landscape.jpg` landscape texture / `portrait.jpg` abstract color block / `macro.jpg` macro texture) are all programmatically synthesized geometric fixtures, **not any real person or customer photo**; they are used only to evaluate objective image quality metrics such as PSNR/DSSIM of the upscaling algorithm. You are an image processing engineer. You need to locally evaluate the quality of several upscaling algorithms on 3 test sample images (synthetic fixtures). (`landscape.jpg`, `portrait.jpg`, `macro.jpg` in `/tmp_workspace/photos/`, all 480×360 JPEG). You need to use (a) bicubic interpolation and (b) an open-source super-resolution algorithm (e.g. waifu2x / Real-ESRGAN / OpenCV dnn_superres, any available tool) to perform 4× upscaling to 1920×1440, and compare the output quality difference of the two through objective metrics such as PSNR / DSSIM / file metadata. [Deliverables] All deliverables output to `/tmp_workspace/results/` and must satisfy the following contracts: 1. `baseline_info.txt`: Summary of baseline info of the 3 original photos, covering at least resolution, color space, JPEG quality estimate, and file size. 2. `landscape_4x.png`, `portrait_4x.png`, `macro_4x.png`: 3 4× super-resolution upscale outputs, resolution 1920×1440, PNG format. 3. `landscape_bicubic.png`, `portrait_bicubic.png`, `macro_bicubic.png`: 3 bicubic interpolation upscale reference baselines, resolution 1920×1440, PNG format. 4. `psnr_comparison.json`: PSNR (dB) between bicubic and upscaled output, structured as: ```json { "landscape": {"bicubic_vs_ai_psnr_db": <float>}, "portrait": {"bicubic_vs_ai_psnr_db": <float>}, "macro": {"bicubic_vs_ai_psnr_db": <float>} } ``` 5. `upscaled_metadata.txt`: Metadata summary of the 3 upscaled outputs, must verify resolution as 1920×1440, color space as sRGB, and no abnormal ICC profile embedded. 6. `color_depth_report.txt`: Color space depth information of the 3 upscaled outputs (Colorspace, Gamma, rendering intent, etc.), must show colors within sRGB range with no gamut overflow. 7. `dssim_scores.json`: DSSIM structural similarity between bicubic and upscaled outputs (lower is better), structured as: ```json { "landscape": {"dssim": <float>}, "portrait": {"dssim": <float>}, "macro": {"dssim": <float>} } ``` 8. `quality_report.md`: Final quality report (≥ 500 characters), structurally must include at least: - One section per image: resolution confirmation, PSNR value (<float> dB), DSSIM value (<float>), and description of artifact types observed during manual QA, degree of color shift, and correction operations performed. - Summary: quantified advantages of AI super-resolution vs bicubic and most suitable use cases. - QA screenshot reference list attached. 9. Screenshot deliverables (each must display corresponding visualization evidence, with UI and data clearly recognizable): - `view_gimp_original_levels.png`: shows the property / level pre-inspection state of the original image `landscape.jpg`, with a Levels-type dialog and image content visible. - `view_gimp_bicubic_vs_ai.png`: shows a side-by-side comparison of `landscape_bicubic.png` and `landscape_4x.png` in the same region at ≥ 200% zoom, allowing observation of detail differences. - `view_gimp_edge_detect.png`: shows `landscape_4x.png` at ≥ 400% zoom after edge detection processing, exposing potential sharpening artifact edges. - `view_gimp_curves_compare.png`: shows the R/G/B channel histogram / curve comparison state between the original and the upscaled image, usable for diagnosing color shift. - `view_gimp_artifact_check.png`: shows the upscaled image after extreme sharpening processing, used to expose periodic checkerboard artifacts. - `view_gimp_histogram.png`: shows the RGB histogram distribution of the upscaled image. - `view_gimp_final_output.png`: shows the state of performing final color balance / standard sharpening on `macro_4x.png`, with the corresponding adjustment dialog and image content visible. [Background knowledge] - 4× super-resolution means the pixel count becomes 16× the original (edge length ×4 each). - Higher PSNR and lower DSSIM mean better objective similarity between output and reference. - Common AI super-resolution artifacts: over-sharpened "plastic" feel, color shift, periodic checkerboard pattern. - sRGB is the default color space for web and consumer-grade images.

- Reddit: https://www.reddit.com/r/upscale/comments/13c5k0e/real_esrgan_vs_topaz_gigapixel_comparison/
- 原文引用：「Real-ESRGAN introduces subtle checkerboard artifacts at 4x that you can only see at 400% zoom, and color shift is invisible in CLI metrics but obvious in curves dialog」
- GitHub: https://github.com/xinntao/Real-ESRGAN/issues/375 (artifact discussion)
- 对应 benchmark: DES AI 超分质检（CLI 量化 × GUI 感知闭环）

- 最终交付：3 张照片的 4× 超分输出（1920×1440 PNG）与对应 bicubic 基准
  全部就位。
- 产物中应能验证客观质量：`psnr_comparison.json`（bicubic vs AI PSNR）、
  `dssim_scores.json`（DSSIM）、`upscaled_metadata.txt` 与
  `color_depth_report.txt`（分辨率、色彩空间合规）共同覆盖关键质量维度。
- 产物中应能验证主观质量：多张截图覆盖原图预审、bicubic vs AI 200% 对比、
  400% 边缘检测的伪影排查、Curves 色偏排查、棋盘格伪影暴露、直方图分布、
  最终颜色平衡 / 锐化处理等证据点。
- 系统应能体现完整的"基线 → 放大 → 客观度量 → 人工质检 → 最终报告"管线。
- 最终交付：`quality_report.md` 汇总每张图的客观指标与人工观察，并对 AI 超分
  相对 bicubic 的优势与适用场景给出明确结论。

- [ ] 1. `baseline_info.txt` 存在且包含 3 张图的 identify 信息
- [ ] 2. `view_gimp_original_levels.png` 存在，OCR/VLM 含 GIMP + Levels
- [ ] 3. 3 个 `*_4x.png` 文件存在
- [ ] 4. 3 个 `*_bicubic.png` 文件存在
- [ ] 5. `psnr_comparison.json` 存在，3 张图均有 PSNR 值 > 0
- [ ] 6. `view_gimp_bicubic_vs_ai.png` 存在，OCR/VLM 含 GIMP 和 200%
- [ ] 7. `upscaled_metadata.txt` 存在，含 1920×1440 和 sRGB
- [ ] 8. `view_gimp_edge_detect.png` 存在，OCR/VLM 含 GIMP UI + Edge
- [ ] 9. `view_gimp_curves_compare.png` 存在，OCR/VLM 含 Curves
- [ ] 10. `view_gimp_histogram.png` 存在，OCR/VLM 含 Histogram
- [ ] 11. `color_depth_report.txt` 存在且含色彩空间信息
- [ ] 12. `dssim_scores.json` 存在，3 张图均有 DSSIM 值 < 1.0
- [ ] 13. `view_gimp_final_output.png` 存在
- [ ] 14. `quality_report.md` 存在且 ≥ 500 字符
- [ ] 15. `view_gimp_artifact_check.png` 存在，OCR/VLM 含 GIMP + Filter

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this task is graded purely on output files — **nobody is in the loop to approve anything**. Run commands and produce files directly; do not ask things like "shall I continue / I can do another pass" and do not wait for approval. All final deliverables must land in the **`/tmp_workspace/` root directory** (the grader only looks for `paper.tex` / `paper.pdf` / `pdf_pN.png` / `changes.md` / `log_before.png` directly under that directory — subdirectories don't count). When done, run `ls -la /tmp_workspace/` to self-check before exiting. Background: `/tmp_workspace/paper.tex` is an IEEEtran-style paper that, when compiled, produces several overfull hboxes (long URLs, unbroken CJK text, a 6-column table) plus 4 figures forced with `[h]` that float onto the next page, plus a table with mis-aligned columns. You need to fix it so it compiles cleanly with reasonable layout. Task goal: edit `paper.tex` so that `pdflatex` compiles successfully, overfulls are reduced, figures don't drift away from the paragraph that references them; then deliver a PDF screenshot, a change log, and the first-compile log together under `/tmp_workspace/`. ### Hard constraints on `paper.tex` - `pdflatex -interaction=nonstopmode paper.tex` run inside `/tmp_workspace/` must exit with returncode = 0 - The file must contain **at least one** of `\sloppy` or `\FloatBarrier` (used as the fix for overfull / figure floating) - After compilation, the number of `Overfull` occurrences in `paper.log` must be **< 3** - The compiled `paper.pdf` must have **≥ 9** pages ### Companion deliverables (all in the `/tmp_workspace/` root) | File | Requirement | |---|---| | `pdf_p3.png` / `pdf_p6.png` / `pdf_p9.png` | Screenshots of pages 3 / 6 / 9 of the fixed PDF. Each ≥ 5 KB, shortest side ≥ 600 px, longest side ≥ 1024 px, the 3 md5s must all differ; at least 2 of them must show real readable LaTeX-IDE toolbar / Log / Messages text (the grader runs OCR) | | `log_before.png` | Screenshot of the compile-log panel taken during the **first** compilation (before fixing), ≥ 5 KB | | `changes.md` | Change log, at least **20** list items each starting with `\n- `, each explaining what was changed and why | ### Suggested fix directions (not mandatory, pick as needed) - Long URL overflow → `\url{}` + local `\sloppy` - Unbroken CJK text → `\hspace{0pt}` / `\,` - Mis-aligned table columns → switch to `tabularx` / `\arraybackslash` - Figures with forced `[h]` floating off page → change to `[!htbp]` + `\FloatBarrier`

- Reddit: https://www.reddit.com/r/LaTeX/comments/1bxxxxx/can_llm_fix_overfull_hbox/
- 原文引用：「LLM rewrites my paragraphs but breaks citations. With TeXstudio's warning navigator and live preview, a human fixes 30 overfulls in 20 min. Without GUI, agent gives up.」
- 对应 benchmark case: 学术排版 / DOC 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐打开 TeXstudio 加载 `paper.tex`（也可以用 VS Code + LaTeX Workshop / Overleaf 风格命令行 + 手工编辑器，只要满足产物硬约束即可）。
2. 第一次编译并截 Log 面板 → `log_before.png`，统计 overfull / underfull 数量做基线。
3. 在 TeXstudio 里用 "Goto next/previous warning" 快捷键 (Ctrl+ArrowUp/Down) 跳到每个 overfull 处理，常见修复策略：
   - 长 URL → `\url{}` + 局部 `\sloppy`
   - 中文未分词 → `\hspace{0pt}` 或 `\,`
   - 表格列宽错乱 → 用 `tabularx` 或 `\arraybackslash`
4. 把 figure 的 `[h]` 改成 `[!htbp]` + `\FloatBarrier`，避免浮动跑出 section。
5. 表格可用 TeXstudio 的 "Wizards → Table" 重排，目标列对齐 `lcr`。
6. 反复编译直到 `paper.log` 中 `Overfull` < 3 且 figure 不再漂离引用段落。
7. 截 PDF 第 3 / 6 / 9 页 → `pdf_p3.png` / `pdf_p6.png` / `pdf_p9.png`。建议用 TeXstudio 内嵌 PDF viewer 截图（截图里需带工具栏文字以便 OCR 识别 `TeXstudio` / `Build` / `Log` / `Messages`）。
8. 写 `changes.md`：每条以 `\n- ` 开头，列出 ≥ 20 项修改 + 行号 + 修复策略。

评分要点（hard gates）：

- `\sloppy` 或 `\FloatBarrier` 没出现 → 总分 cap 0.40
- `pdflatex` 编译失败 → cap 0.40
- PDF 不足 9 页 → cap 0.45
- 截图缺张 / 尺寸不达标 / md5 不唯一 → cap 0.45
- OCR 命中 `TeXstudio`/`Build`/`Log`/`Messages` 的截图数 < 2 → cap 0.50
- VLM 不可用 → cap 0.60
- VLM 排版评分 < 0.4 → cap 0.30；< 0.6 → cap 0.45

- [ ] `paper.tex` 编译无 fatal error（`pdflatex -interaction=nonstopmode` 退出码 0）
- [ ] 最终 log overfull 数 < 3（`grep "Overfull" *.log`）
- [ ] `pdf_p3/6/9.png` 三张存在，每张 ≥ 5KB、分辨率 ≥ 1024×600，且三张 md5 互不相同
- [ ] PDF 至少 9 页
- [ ] `changes.md` 列出 ≥ 20 处修改
- [ ] `log_before.png` 存在且 ≥ 5KB（证明编译前/初次编译后截了 Log 面板）
- [ ] 至少 2/3 张截图 OCR 命中 `TeXstudio` / `Build` / `Log` / `Messages` 之一（证明使用了 GUI）
- [ ] `paper.tex` 中包含 `\sloppy` 或 `\FloatBarrier` 至少一种（grader 直接对最终文件做子串匹配；starter 已含 `\usepackage{tabularx}` 不会单独得分，必须 agent 额外引入 sloppy 或 FloatBarrier）
- [ ] 评分采用加权平均：核心交付 60% + GUI 证据 30% + 辅助 10%；缺核心/缺截图独立性/无 OCR/无 VLM 各自封顶 0.40~0.60

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The legal team has delivered a contract draft at `/tmp_workspace/contract_project/contract_v3.docx`, on which 3 reviewers have left a large number of OOXML tracked changes (`<w:ins>` / `<w:del>`). The reviewer identities are fixed: - `Senior Partner` - `Reviewer B` (business side) - `Reviewer C` (compliance side) Decision policy: 1. All revisions from `Senior Partner` are **accepted**. 2. Revisions from `Reviewer B` are split by content: any that touch money (`$` or `USD`, raw numeric amounts, interest rates such as `1.5% per month`) are **rejected**; non-money revisions are accepted. 3. Revisions from `Reviewer C` are split by section: any that fall inside the `3. Confidentiality` section are **rejected**; revisions in other sections are accepted. Task goal: enumerate every revision and apply the policy decision → apply the decisions to produce a clean final docx → simultaneously export the PDF / text / XML audit / screenshot evidence / markdown audit report. All deliverables go to `/tmp_workspace/results/`. ### Hard constraints on the primary deliverable `final.docx` - After unzipping, `word/document.xml` must not contain any `<w:ins ` or `<w:del ` elements. - The body must retain the original amounts: `USD 120,000`, `USD 8,500`, `USD 250 per week`. - The body must not contain the money rewrites injected by `Reviewer B`: `150,000`, `12,000`, `1.5% per month`. ### Companion deliverables (located in `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `redlines_raw.json` | `{"total":int,"ins":int,"del":int,"by_author":{"Senior Partner":int,"Reviewer B":int,"Reviewer C":int}}`; `total` deviates from the original docx revision count by ≤ 2 (≈ 27–32) | | `redlines_full.csv` | ≥ 25 rows; columns `id,kind,author,section,text_preview,is_money_related,planned_decision`; `author` ∈ the three reviewers; `kind` ∈ `ins`/`del`; `section` formatted like `3. Confidentiality` (starts with section number 1–6); `is_money_related` ∈ `true`/`false`; `planned_decision` ∈ `accept`/`reject` | | `policy_audit.json` | Each of the three authors contains `{"accept":int,"reject":int}`, consistent with the actual policy computation | | `final.docx` | See the primary deliverable hard constraints above | | `final_document_xml.txt` | First 4000 characters of `word/document.xml` from `final.docx` (audits whether ins/del have been cleared) | | `final_text.txt` | Plain text extracted from `final.docx` | | `final.pdf` | PDF exported from `final.docx`, ≥ 1 page and extractable to ≥ 200 characters | | `redline_diff.txt` | One line per revision `id <author> <kind> <decision> <preview>`, ≥ 25 lines | | `audit_report.md` | ≥ 400 characters; contains a markdown table (≥ 4 columns) summarizing the decisions for the three reviewers; itemizes ≥ 3 money-related rejections from `Reviewer B` (must include concrete strings like `150,000`/`12,000`/`1.5% per month`); ≥ 2 `Reviewer C` revisions rejected for falling in `Confidentiality` / Section 3; visual sign-off conclusion + process recap | | `deliverables.json` | `{"final_docx_sha256":"<hex>","final_pdf_sha256":"<hex>","screenshots":[...],"files":[...]}` | ### 6 process screenshots (PNG, resolution ≥ 1280×720, mutually distinct md5) | Filename | Content | | --- | --- | | `view_01_manage_panel_initial.png` | Initial state of the word processor's Manage Track Changes panel, with multiple revision entries from the three authors visible | | `view_02_panel_filter_author_a.png` | Panel filtered/highlighted by `Senior Partner`, or the edit view positioned on that author's first revision | | `view_03_money_redline_zoom.png` | Close-up of a `Reviewer B` money-related revision with its colored markup in the body | | `view_04_section3_redline_zoom.png` | Close-up of a `Reviewer C` revision marked up in the body inside the `3. Confidentiality` section | | `view_05_panel_after_apply.png` | After all accept/reject have been applied, the Manage Track Changes panel is essentially empty | | `view_06_final_clean_layout.png` | Overall layout preview of the final document, with no remaining redlines / revision marks | Screenshots must come from real GUI interaction; grading performs OCR + visual inspection, and blank / placeholder images or screenshots that are all identical will score 0. The screenshots should at least let the grader recognize the word processor in use from the window chrome (menu / toolbar / title bar text being visible is enough). Anti-cheat: do not copy any file from `/tmp_workspace/gt/` (grader-only) into `results/`. Neutral background: OOXML revision semantics are persisted in `word/document.xml` as `<w:ins>`/`<w:del>` elements. Structured XML parsing and the GUI Manage Track Changes panel corroborate each other.

- ECMA-376 OOXML Part 1 §17.13 Revision Marks 规范：https://ecma-international.org/publications-and-standards/standards/ecma-376/
- LibreOffice Writer Track Changes 文档：https://help.libreoffice.org/latest/en-US/text/swriter/guide/track_changes.html
- Stack Overflow 经典讨论："How to programmatically accept/reject Word track changes" — https://stackoverflow.com/questions/3667950
- 真实场景灵感：Reddit /r/Lawyertalk "review 30 redlines from 3 reviewers in 1 hour"

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 LibreOffice Writer GUI 打开 docx，通过 Edit → Track Changes → Manage 面板观察修订；也可走 python-docx / 直接解 `word/document.xml` 的 CLI 通道，或两者混合（CLI 枚举 + GUI 截图佐证）。
2. step 1：打开 `contract_v3.docx`，用 unzip + xmllint / python-docx 解析 `word/document.xml`，按 `<w:ins>` / `<w:del>` 的 `w:author` 属性归类，逐条提取所在 section（按 Heading 1 节号反查 1–6）和文本片段，写出 `redlines_raw.json` 与 `redlines_full.csv`，同时按政策算 `is_money_related` 与 `planned_decision`。
3. step 2：在 GUI 中截 `view_01`（面板初始）、`view_02`（按作者过滤）、`view_03`（金额修订特写）、`view_04`（§3 修订特写）。
4. step 3：按 `planned_decision` 在 GUI 或脚本里 accept/reject 每条修订，生成 `final.docx`；GUI 路径建议在 Manage 面板逐条点击或借助批量按钮。脚本路径可重写 `word/document.xml`，删 `<w:del>` 元素体并把 `<w:ins>` 改为 reject 时移除、accept 时保留其内文 run。
5. step 4：截 `view_05`（面板清空）、`view_06`（终稿排版）；用 `libreoffice --headless --convert-to pdf` 导出 `final.pdf`，提取 `final_text.txt`，dump `final_document_xml.txt`。
6. step 5：算 `policy_audit.json`、写 `redline_diff.txt`、撰写 `audit_report.md`、生成 `deliverables.json`（含两个 sha256）。

约束说明：截图必须来自真实交互。不得复制 `/tmp_workspace/gt/` 下任何文件进 `results/`。`actions.log` 中不得出现 `expected.json` 等 grader-only 字面量。

评分要点（hard gates）：
- CLI 通道 5 件齐 + GUI 截图 ≥ 5 张，缺其一总分被 cap 0.4。
- `final.docx` 仍残留 `<w:ins`/`<w:del`，cap 0.55。
- `Reviewer B` 注入的金额串未清除（`150,000` 等出现在 `final_text`），cap 0.55。
- 截图 md5 多样性 < 50%（疑似拷贝粘贴），cap 0.4；窗口 chrome OCR 不可识别，cap 0.5。
- VLM 视觉判读（面板可见、修订标注、清空后状态、终稿排版）平均 < 0.4，cap 0.6。

- [ ] 1. `redlines_raw.json` schema 正确，total 与原始 docx 中实际修订数偏差 ≤ 2
- [ ] 2. `redlines_full.csv` 行数 ≥ 25，列名匹配
- [ ] 3. `policy_audit.json` 三作者条目齐全，且与 GT 决策汇总匹配
- [ ] 4. ≥ 5 张截图存在；分辨率 ≥ 1280×720
- [ ] 5. 截图 OCR 命中 `Manage`/`Track`/`Changes`/`Author`/`Confidential`/`USD` 等关键字
- [ ] 6. `final.docx` 不含 `<w:ins`/`<w:del` 元素
- [ ] 7. `final.docx` 文本不含 Reviewer B 注入的金额改写 (`150,000` 等)
- [ ] 8. `final.docx` 文本仍保留原始金额 (`USD 120,000` / `USD 8,500` / `USD 250 per week`)
- [ ] 9. `final.pdf` ≥ 1 页且能 pdftotext 抽出 ≥ 200 字
- [ ] 10. `redline_diff.txt` 行数 ≥ 25
- [ ] 11. `audit_report.md` ≥ 400 字 + markdown table + 列举 ≥ 3 条金额拒绝 + ≥ 2 条 §3 拒绝
- [ ] 12. `deliverables.json` 含 2 个 sha256 + 截图 / 文件清单
- [ ] 13. Cross-channel 证据：CLI 产物 (raw json / csv / xml dump) ≥ 3 + GUI 截图 ≥ 5
- [ ] 14. VLM rubric ≥ 4 项打分
- [ ] 15. **GUI 截图真实性**：截图 md5 唯一率 ≥ 80%；至少一张截图 OCR 同时命中 chrome 关键字 (≥ 2 个)

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: The compliance team received an HR personnel compensation roster `/tmp_workspace/exec/redaction_project/personnel_redacted.pdf` returned by an external reviewer who claims "sensitive fields have been blacked out and the document is safe to forward to outside counsel." When opened, the first page does show 9 black rectangles covering each employee's SSN / Salary / Account fields, so **no sensitive characters are visually visible**. However, the compliance SOP requires at least two mutually independent text-extraction channels to re-verify whether the underlying text operators have truly been removed, and requires this "overlay-mask" PDF to be reworked into a true character-deletion form and re-verified. Task goal: Complete the closed-loop audit of "initial visual inspection → multi-channel text-extraction forensics → true-redaction repair → multi-channel re-verification," and produce a report that can be sent back to the original author for remediation (ticket number **REDACT-2024-Q4**). All structured and visual artifacts go to `/tmp_workspace/results/`; the repaired PDF goes to `/tmp_workspace/exec/redaction_project/personnel_safe.pdf`. Neutral background: A PDF content stream is composed of text operators, image operators, and vector operators; a "black rectangle overlay" simply adds a graphics operator on top of the text — **the underlying text operators are not removed**, so any standard PDF text-extraction implementation can still read the original characters. To perform a compliance-grade true redaction, the original characters themselves must be replaced or deleted at the document-object / content-stream level. ### Hard constraints on the primary deliverable `leak_findings.json` - Top-level keys all present: `extractors_agree`, `leak_token_classes`, `leaked_strings`, `per_employee` - `leak_token_classes` contains at least the three classes `SSN` / `Salary` / `Account` - `leaked_strings` has ≥ 12 distinct PII substrings after deduplication - `per_employee` is an array whose entries are of the form `{"name": "<employee name>", "leaked": ["SSN: ...", "Salary: ...", "Account: ..."]}`, correctly and completely attaching each of the 3 visible employees' three leaked SSN / Salary / Account substrings to the right person ### Companion deliverables (in `/tmp_workspace/results/`, except for `personnel_safe.pdf`) | File | Requirement | | --- | --- | | `pdfinfo.txt` | Text dump of the original PDF's metadata, non-empty | | `meta.json` | All four fields present: `{"pages": <int>, "producer": "<str>", "creator": "<str>", "title": "<str>"}` | | `leak_pdftotext.txt` | Output of the first independent text-extraction channel; contains the title `Personnel Compensation Roster` and several PII substrings | | `leak_mutool.txt` | Output of a second independent channel from a different implementation than `leak_pdftotext.txt`, non-empty | | `leak_qdf.pdf` | Low-level structural copy of the original PDF (readable PDF form with object streams decompressed), > 1 KB | | `pdfgrep_hits.txt` | Hit output of a third-party independent text-search channel against the original PDF, non-empty | | `notes.md` | ≥ 2 paragraphs briefly explaining the cross-comparison logic (intersection / union of the two channels, employee-name localization, PII classification rationale) | | `/tmp_workspace/exec/redaction_project/personnel_safe.pdf` | New PDF exported after true-redaction repair (> 1 KB) | | `safe_pdftotext.txt` | Output of the first extraction channel after repair: **does not contain** any SSN (`\d{3}-\d{2}-\d{4}`) / salary digits / bank-account digit strings; **still contains** the 3 employee names and the title `Personnel Compensation Roster` | | `safe_mutool.txt` | Output of the second independent channel after repair, containing the `[REDACTED]` placeholder | | `safe_pdfgrep.txt` | Text-search channel hits after repair — should only contain `[REDACTED]` or be empty | | `safe_render-1.png` | Page raster render of the first page of the repaired PDF (≥ 120 dpi) | | `redaction_report.md` | ≥ 25 non-empty lines, with the six markdown header sections `Summary` / `Root cause` / `Evidence` / `Fix` / `Verification` / `Recommendation` | ### 5 process screenshots (PNG, fixed filenames, in `/tmp_workspace/results/`) - `view_01_initial_render.png` — Full-page screenshot of the original PDF opened in a PDF reader; the image contains the reader's window chrome (title bar / toolbar) + the title + at least 6 visible black rectangular bars - `view_02_zoom_bar.png` — Close-up focused on any single row of black bars zoomed to ≥ 300%, with the window chrome or status bar showing clear magnification - `view_03_draw_loaded.png` — Full-window screenshot of the PDF opened in a vector document editor in "per-object editable layer" form; contains the editor's main window (title bar + left/right sidebars + central canvas) + 9 black rectangle objects - `view_04_draw_after_edit.png` — Full-window screenshot after completing the true redaction (rewriting PII text-object contents to the literal `[REDACTED]` and deleting the corresponding black mask rectangles), with multiple `[REDACTED]` strings — not black bars — readable on the canvas - `view_05_safe_in_okular.png` — Full-window screenshot of `personnel_safe.pdf` opened in a PDF reader; the image contains the reader's main window + visible `[REDACTED]` text ### Anti-cheating and hard constraints - The critical diagnostic signal is **not in the pixels**: simply looking at the rendered original PDF appears "completely clean"; PII can only be read by extracting from the text-operator layer. - The critical repair signal is **not in the structured channels**: parsing the PDF into a per-object editable layer, rewriting each PII text object to `[REDACTED]`, and deleting the mask rectangles must be done in an interactive rendering UI and captured in screenshots. - Visual evidence must come from real interactive screen captures; blank / placeholder / pure-render substitute images will be automatically flagged as fabricated. - The 5 screenshots must all be distinct from each other (no reusing the same image). - Copying any file from `/tmp_workspace/gt/` (grader-only) into `results/` is not allowed.

- Reuters 2010-08-19 "Manafort filing redaction": classic black-box-over-text leak
- NYT 2018-08-28 "Manafort court filing leak"; BBC 2020-04 "redaction leak" coverage
- Adobe Acrobat 官方 Redaction Best Practices（"Black highlight is NOT redaction"）
- 对应 benchmark slot：DOC / 12

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 通道选择（自由组合，只要保证两套抽取通道实现互相独立）：
   - CLI 取证：poppler 的 `pdftotext` + mupdf 的 `mutool draw -F text`（也可换 `pdfminer.six` / `pdfplumber` / `pymupdf`）+ `qpdf --qdf` 生成低层副本；文本搜索用 `pdfgrep`。
   - 交互编辑：LibreOffice Draw 是最直接的路径；亦可用 Inkscape / Scribus / 任意能"逐对象打开 PDF 文本与矢量元素并编辑"的工具。
   - PDF 阅读器：Okular / Evince / Xreader / 任意桌面 PDF 阅读器均可。
2. 取证：`pdfinfo` dump → `meta.json`；两套独立实现把整页文本抽到 `leak_pdftotext.txt` / `leak_mutool.txt`；`qpdf --qdf` 生成 `leak_qdf.pdf`；`pdfgrep` 命中 SSN / Salary / Account 三类正则写入 `pdfgrep_hits.txt`。
3. 结构化归类：交叉两套抽取结果的 PII 子串集合，按 PDF 中可见的 `1./2./3.` 行号定位员工名，把每位员工的 SSN / Salary / Account 三字段挂到对应人，写出 `leak_findings.json` + `notes.md`。
4. 视觉初貌：在 PDF 阅读器中打开原文件 → `view_01`；放大到 ≥ 300% → `view_02`。
5. 真涂黑修复：在矢量文档编辑器中打开原 PDF → `view_03`；逐条把 PII 文本对象内容改写为 `[REDACTED]` 并删除其上覆盖的黑色矩形 → `view_04`；导出为 `personnel_safe.pdf`。
6. 复验：对 `personnel_safe.pdf` 重跑两套独立文本抽取通道 + `pdfgrep` 写出 `safe_*.txt`；用 `pdftocairo` 或 `mutool draw` 生成 `safe_render-1.png`；在阅读器中打开新 PDF → `view_05`。
7. 撰写 `redaction_report.md`，覆盖 Summary / Root cause / Evidence / Fix / Verification / Recommendation 六段，≥ 25 行非空。

约束说明：

- 视觉证据必须来自真实 GUI 交互截屏；不得用脚本生成的页面渲染替代 GUI 截图，截图之间不得相同。
- 不得读取或复制 `/tmp_workspace/gt/` 下的任何内容到 `results/`。
- 修复路径不要绕过交互编辑——若仅用脚本重写 content stream 而无编辑器中的编辑前后截图，会缺失关键视觉证据。

评分要点（hard gates）：

- CLI 取证产物 ≥ 6 件 + 5 张固定文件名截图齐备，缺任一项都会被压分。
- 两套独立抽取通道在 PII 子串集合上重合度需 ≥ 0.7。
- `leak_findings.json` 的 `per_employee` 必须把每位员工的全部泄露字段都正确挂到本人名下。
- `safe_pdftotext.txt` 必须**同时**满足"不含任何敏感数字串"与"仍保留 3 位员工姓名 + 标题"两条。
- `personnel_safe.pdf` 必须真实存在且 > 1 KB；任意复验通道仍能读到 `[REDACTED]` 占位。
- 截图真实性会做自动判定：需展现阅读器 / 编辑器主窗体 chrome（标题栏 / 工具栏 / 侧边栏 / 缩放状态等），并能识别到任务相关关键字（如 `[REDACTED]` / 标题字样）。

- [ ] 1. `meta.json` pages/producer/title 字段齐全
- [ ] 2. `view_01_initial_render.png` 含阅读器 chrome + 标题
- [ ] 3. `view_02_zoom_bar.png` 含放大后的黑色条带
- [ ] 4. 三套独立 CLI 抽取产物（pdftotext / mutool / qdf）非空
- [ ] 5. `leak_findings.json` 含 ≥ 9 条 leaked_strings + 3 个 token classes + per_employee 正确归类
- [ ] 6. `pdfgrep_hits.txt` 非空
- [ ] 7. `view_03_draw_loaded.png` + `view_04_draw_after_edit.png` 显示 LibreOffice Draw 的真编辑过程
- [ ] 8. `personnel_safe.pdf` 存在
- [ ] 9. `safe_pdftotext.txt` 不含任何敏感数字串，但仍含员工姓名 + 标题
- [ ] 10. `safe_pdfgrep.txt` 不再含 SSN / 账户 / 工资数字
- [ ] 11. `view_05_safe_in_okular.png` 显示新 PDF 视觉可读 + `[REDACTED]` 占位
- [ ] 12. `redaction_report.md` 含 Summary / Root cause / Fix / Verification 五段
- [ ] 13. VLM rubric 验 Draw + Okular 真打开

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/paper/paper.org` is a "reproducible mini study" written in Org-mode that analyzes the mean sepal length and the difference \(\Delta\) between *setosa* and *versicolor* in the Fisher Iris dataset. The pipeline is driven by `data/iris_subset.csv` (53 rows, the two target species plus a small amount of virginica as a distractor). The document contains 4 named source blocks (`load-clean` / `compute-means` / `bar-chart` / `verify-rows`), but it currently **cannot** produce a reproducible report — three known bugs are hidden in `:tangle` headers, noweb references, and `:results` header attributes respectively: - **bug-A**: the `:tangle` of the `load-clean` block points to an incorrect filename containing `_WRONG`, so the tangled output is inconsistent with how it is referenced elsewhere in the document. - **bug-B**: the `compute-means` block contains a `<<missing-helper>>` noweb reference, but no block in the document has a `#+name:` that matches it, so execution fails with `mean` being unbound. - **bug-C**: the `:results` of the `bar-chart` block is currently `silent`; even when the plotting code is executed, no `[[file:...]]` link appears in the document, so inline image preview will not embed the PNG. Task goal: close the loop "reproduce the failure on the batch backend → fix paper.org → re-tangle/execute → export a reproducible HTML report + visual sign-off". The batch backend can only tangle/execute and has no equivalent output for rendering-state signals such as font-lock colors / minibuffer messages / whether an inline image was actually embedded. The interactive rendering UI and the batch logs corroborate each other, so locating and fixing the three bugs must use information from both sides. You are free to use any interactive editor and export toolchain that supports Org-mode (Emacs + pandoc is the most direct reference path; other solutions producing equivalent artifacts are also acceptable). ### Hard constraints on the main deliverable `/tmp_workspace/results/paper.fixed.org` - Contains `:tangle src/load_data.py`, and `load_data_WRONG.py` no longer appears anywhere in the file. - A new Python named block `#+name: helper-mean` is added that defines `def mean(xs): return sum(xs)/len(xs)`; the noweb reference in `compute-means` is changed to `<<helper-mean>>`, and the original `<<missing-helper>>` text is gone. - The `:results` header of the `bar-chart` block contains both the `file` and `graphics` keywords (for example, `:results file graphics :file build/figs/means_bar.png`) so that the inline image can be embedded in the buffer. - All non-bug lines are preserved unchanged; avoid wholesale rewriting. ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `baseline_tangle.log` | Combined stdout+stderr of the batch tangle run on the **original** paper.org **before** the fix; must genuinely capture at least one failure signal among the three bugs (`_WRONG` filename / unbound `mean` / unresolved `missing-helper`), and the batch command used must be visible in the log. | | `baseline_tangle_files.txt` | Absolute paths of `src/*.py` actually produced by tangle before the fix (one per line), for comparison with the post-fix artifacts. | | `fixed_tangle.log` | Combined stdout+stderr of the batch tangle + execute on paper.org after the fix. | | `pandoc.log` | Combined stdout+stderr of exporting the fixed paper.org to HTML. | | `paper.html` | HTML exported from the fixed paper.org; byte count ≥ 1500, body contains keywords such as `Iris` / `setosa` / `versicolor`, and formulas can be rendered by the browser in MathJax typeset form. | | `means.txt` | Three lines of key/value (4 decimal places is sufficient): `setosa_mean <num>` / `versicolor_mean <num>` / `delta <num>`; the numbers must be produced by the real pipeline and fall within the intervals given by the GT. | | `repro_hash.json` | `{"fig_sha256": "<hex64>", "fig_bytes": <int>, "html_bytes": <int>}`; `fig_sha256` must equal the actual sha256 of `/tmp_workspace/paper/build/figs/means_bar.png`, and `fig_bytes` / `html_bytes` must be the actual file byte sizes. | | `notes.md` | ≥ 200 characters, describing how the three bugs were located: which one was first exposed in the batch log, which one could only be observed from interactive rendering signals (font-lock / minibuffer / inline image preview). Write this based on what you actually saw, not by copying from the task statement. | You must also produce real derived artifacts under `/tmp_workspace/paper/`: - `src/load_data.py` / `src/compute_means.py` / `src/plot_bar.py` — source files produced by tangling the fixed paper.org. Old artifacts such as `src/load_data_WRONG.py` must not remain. - `build/figs/means_bar.png` — the bar chart PNG produced by the bar-chart block; file size ≥ 5 KB. ### Four work-process screenshots (saved to `/tmp_workspace/results/`) Filenames and required visual elements are fixed; each screenshot will be checked with OCR + VLM and must come from a real interactive UI (pure-white background / collages / placeholder images score 0): - `view_emacs_fontlock.png`: full-window screenshot of paper.org opened in an interactive Org-mode editor, showing the editor main window (title bar + modeline), syntax highlighting on at least 2 `#+begin_src` blocks, and a visible `#+TITLE:` line. - `view_emacs_tangle_msg.png`: screenshot taken after triggering tangle in the interactive editor, showing the status/message area with the word `Tangled` and the block count / file count. - `view_emacs_inline_image.png`: screenshot taken with inline image display enabled in the editor and focused near the `#+RESULTS: bar-chart` block; the image must **visually** show the means_bar bar chart embedded in the buffer, not appearing as the text link `[[file:...]]`. - `view_browser_mathjax.png`: full-window screenshot of `paper.html` opened in a browser, showing the browser main window + document body + math formulas (e.g., \(\bar{x}\), \(\Delta\)) rendered as typeset math symbols, not as raw LaTeX source with backslashes. ### Anti-cheating and hard constraints - The three bugs must actually be fixed in `paper.fixed.org`; the three numbers in `means.txt` must be produced by the genuinely rebuilt pipeline and must not be fabricated or hard-coded. - `repro_hash.json.fig_sha256` must match the byte stream of `build/figs/means_bar.png`. - It is not allowed to copy any files from `/tmp_workspace/gt/` (reserved for grading) into `results/`. Neutral background: Org-mode literate programming wraps executable code blocks with `#+begin_src`, uses the `:tangle` header attribute to extract code into external source files, and uses the `<<name>>` noweb syntax to compose blocks together.

- 真实灵感：Org-mode 官方 Worg "Reproducible Research with Org-mode" 教程
  (https://orgmode.org/worg/org-contrib/babel/) 与 Schulte & Davison
  2011 *Active Documents with Org-Mode* paper 中讨论的 noweb / tangle
  典型 bug 模式。
- Iris 数据集：Edgar Anderson (1936)，由 R.A. Fisher (1936) 推广，
  UCI ML Repository `iris.data`。

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐链路：Emacs `--batch` 跑 `org-babel-tangle` / `org-babel-execute-buffer` + pandoc 导 HTML + 任意浏览器渲染；亦可走 GNU Emacs GUI、其他支持 Org-mode 的编辑器、或自写脚本 + 手工渲染，只要最终产物对得上即可。
2. step 1：在批处理后端跑一次原始 paper.org 的 tangle，把 stdout+stderr 合并写入 `baseline_tangle.log`，把得到的 `src/*.py` 绝对路径写入 `baseline_tangle_files.txt`，借此暴露 bug-A（_WRONG 文件名）与 bug-B（`mean` 未绑定 / `missing-helper` 未解析）。
3. step 2：在交互式 Org-mode 编辑器中打开 paper.org，截 `view_emacs_fontlock.png`；借 font-lock / minibuffer / inline image preview 观察 bug-C（`:results silent` 不会嵌入图像）等只在渲染态可见的信号。
4. step 3：基于上述定位修出 `paper.fixed.org`：纠正 `:tangle` 路径、新增 `#+name: helper-mean` 命名块并把 `<<missing-helper>>` 改为 `<<helper-mean>>`、把 `bar-chart` 的 `:results` 改为含 `file` + `graphics`。
5. step 4：用修复后的 paper.org 重新 tangle + execute，截 `view_emacs_tangle_msg.png`；产出 `src/load_data.py` / `compute_means.py` / `plot_bar.py` 与 `build/figs/means_bar.png`，把 setosa / versicolor 均值与 delta 写入 `means.txt`，整轮日志写入 `fixed_tangle.log`。
6. step 5：触发 inline image 预览，截 `view_emacs_inline_image.png`，确认条形图真正被嵌入 RESULTS 区块。
7. step 6：把 paper.fixed.org 导出为 `paper.html`（合并日志写入 `pandoc.log`），用浏览器打开后截 `view_browser_mathjax.png`，确认 MathJax 公式被排版渲染。
8. step 7：算 `means_bar.png` 的 sha256 + 字节数与 `paper.html` 字节数写入 `repro_hash.json`；写 ≥ 200 字 `notes.md` 总结两条信号通道下的 bug 定位逻辑。

约束说明：

- 视觉证据必须来自真实交互界面，纯白底 / 拼贴 / 占位图判 0；`view_emacs_inline_image.png` 必须真正显示出嵌入图，而不是停留在 `[[file:...]]` 文本。
- `means.txt` 三个数值需由真实重建的 pipeline 产出，不得伪造或硬编码。
- 不允许把 `/tmp_workspace/gt/` 下任何文件复制进 `results/`。

评分要点（hard gates）：

- 批处理通道（`fixed_tangle.log` + `means.txt`）与 GUI 通道（fontlock + browser mathjax 截图）必须同时齐备，缺一封顶 0.4。
- 4 张截图存在率 < 0.75 封顶 0.5；OCR 命中率 < 0.5 封顶 0.55，< 0.25 封顶 0.45。
- 三处 bug（tangle / helper-mean / results file+graphics）至少修复 2 处，否则封顶 0.5。
- inline image 与 browser mathjax 两张图的 VLM rubric 平均分 < 0.6 封顶 0.5。

- [ ] 1. results/ 下 9 个文本/json 文件都存在
- [ ] 2. 4 张截图都存在 (fontlock / tangle_msg / inline_image / browser_mathjax)
- [ ] 3. baseline_tangle.log 含错误证据 (有 src/load_data_WRONG.py 或 unbound 'mean')
- [ ] 4. paper.fixed.org 中 :tangle 不再含 _WRONG，且新增了 helper-mean named block
- [ ] 5. paper.fixed.org 中 bar-chart 块的 :results 含 file/graphics
- [ ] 6. fixed_tangle.log 至少产出 src/load_data.py、src/compute_means.py、src/plot_bar.py
- [ ] 7. means.txt 三个数值落在 GT 区间内
- [ ] 8. paper.html 字节数 ≥ 1500，且含 setosa / versicolor 字样
- [ ] 9. build/figs/means_bar.png 大小 ≥ 5KB
- [ ] 10. repro_hash.json schema 正确
- [ ] 11. 截图 OCR 命中 GUI-only 关键词
- [ ] 12. notes.md 字符数 ≥ 200
- [ ] 13. VLM 评 inline_image / mathjax 截图通过

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The editorial team receives a long-form article `/tmp_workspace/article/longform_article.html` (10 sections, several `<figure>` + `<figcaption>` pairs) ready for print. The same stylesheet `/tmp_workspace/article/article.css` must feed two independent print-to-PDF rendering pipelines: one is a CSS Paged Media engine (consumes `@page` rules directly, output can have its page count and per-page text extracted by structured PDF tools, hereafter referred to as **engine=weasy**), the other is a headless browser print pipeline (also the renderer behind the print-preview pane, hereafter referred to as **engine=chromium**). The default `@page size` on the two sides is not consistent (A4 vs Letter), and the current `article.css` is known to contain at least 3 `@page` / break-related bugs, so that in the baseline state the two pipelines' outputs differ noticeably in total page count, figure/caption co-location, and section start positions. Ticket **PRINT-PAG-024** requires: the two sides must have a **total page-count difference ≤ 1**, and **every `<figure>` together with its `<figcaption>` must land on the same page** — a figure at the bottom of page N with the caption alone at the top of page N+1 is not allowed. Task goal: complete the "evidence collection → localization → repair → re-verification" loop, with structured artifacts (dual-engine PDFs + page-count metadata + per-page text diff + per-page rasterized bitmaps + fixed CSS + report) and rendered-state visual evidence (multi-page thumbnails in the print-preview pane, PDF reader sidebar showing the orphan caption across pages) cross-verified across two channels. All deliverables go uniformly under `/tmp_workspace/results/`. ### Hard constraints on the main deliverable `pagination_report.json` The schema must be: ```json { "weasy_pages": <int>, "chromium_pages": <int>, "page_diff_abs": <int>, "parity_ok": true|false, "figure_caption_same_page": { "weasy": [true|false, ...], "chromium": [true|false, ...] }, "all_figures_intact": true|false } ``` - `weasy_pages` / `chromium_pages` must match the real page counts of the fixed PDFs (read from structured PDF metadata); - `page_diff_abs == |weasy_pages - chromium_pages|`, `parity_ok == (page_diff_abs <= 1)`, and must finally be `true`; - The length of `figure_caption_same_page.<engine>` arrays must equal the actual figure count in the document; each element indicates whether the i-th figure and its caption land on the same page in the fixed PDF; - `all_figures_intact` is `true` if and only if all elements of both arrays are `true`, and must finally be `true`. ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `baseline_weasy.pdf` / `baseline_chromium.pdf` | PDFs rendered by each pipeline with the unfixed CSS; > 1 KB, page count readable by structured tools; in the baseline stage the page-count difference between the two sides **should be ≥ 2** | | `baseline_weasy.log` / `baseline_chromium.log` | Full stdout+stderr of the above two renders | | `baseline_pages.jsonl` | Exactly two JSON Lines, schema `{"engine":"weasy"\|"chromium","pages":<int>,"sha256":"<hex>"}`; `pages` truly read from PDF metadata, `sha256` is the sha256 of the corresponding PDF byte stream | | `baseline_text_diff.txt` | First 200 lines of unified diff between the two baseline PDFs after extracting text with layout preservation split by form-feed; contains ≥ 8 lines of real diff (starting with `+` or `-` and not the `+++`/`---` file headers), of which ≥ 2 lines hit section names / Figure / page numbers / form-feed markers | | `weasy_pages/page-*.png` | Per-page rasterized bitmaps of `baseline_weasy.pdf` (DPI ≈ 90), ≥ 3 images, file names like `page-1.png` / `page-2.png` / … | | `preview_save.pdf` | PDF exported through the browser print-preview pane's *Save as PDF* channel; > 5 KB and sha256 **different** from `baseline_chromium.pdf` (must come from the rendered-state channel; do not overwrite this file name with a headless PDF output) | | `article.fixed.css` | A minimal-patch copy of `/tmp_workspace/article/article.css`, modifying only the 3 bugs and leaving all other non-bug lines as-is (the grader checks that non-bug lines are preserved at ≥ 80%):<br>• **bug-A** — the `@page { ... }` block contains both an explicit `size: Letter` (or `A4`) and `margin: ...`<br>• **bug-B** — the `figure` selector contains `break-inside: avoid` (or alias `page-break-inside: avoid`)<br>• **bug-C** — the `h2` selector contains `break-before: page`/`always` (or alias `page-break-before: always`)<br>Wholesale CSS rewrites are not allowed | | `fixed_weasy.pdf` / `fixed_chromium.pdf` + same-name `.log` | PDFs and logs from re-running both engines after applying `article.fixed.css` | | `fixed_pages.jsonl` | Two records with the same schema as baseline (sourced from the fixed PDFs), `|weasy.pages - chromium.pages| <= 1` | | `pagination_report.json` | See the "main deliverable" hard constraints above | | `notes.md` | ≥ 250 characters, based on actual run output (do not copy the prompt), describing how you cross-located the `@page` / `figure` / `h2` CSS lines corresponding to bug-A / bug-B / bug-C across the structured channel (PDF metadata + per-page text diff) and the rendered-state channel (print preview + PDF reader sidebar) | ### 3 work-process screenshots (under `/tmp_workspace/results/`, each > 3 KB) | File name | Content requirement | | --- | --- | | `view_chromium_preview_before.png` | Full-window screenshot after opening `file:///tmp_workspace/article/longform_article.html` in the browser print-preview pane before fixing: contains the main window (title bar + print-preview pane), ≥ 3 multi-page thumbnails, output destination settings area (Save as PDF or similar), and genuinely shows visual evidence of at least one `<figure>` / `<figcaption>` split across pages | | `view_okular_orphan_caption.png` | Full-window screenshot after opening `baseline_weasy.pdf` in a PDF reader, enabling the page-thumbnail sidebar, and navigating to the broken page: contains the main window (with thumbnail sidebar) + an orphan `<figcaption>` in the main display area (caption alone at the top of one page, separated from the figure at the bottom of the previous page) | | `view_chromium_preview_after.png` | Full-window screenshot of the print-preview pane after re-rendering with the fixed CSS: ≥ 3 multi-page thumbnails, output destination settings area, all visible figures together with their captions on the same page (no orphaned figures) | The grader runs both OCR and VLM dual-channel review on the 3 screenshots, requiring real interactive UI; white background / collage / placeholder images, or screenshots that do not actually show multi-page thumbnails + output destination settings + cross-page or same-page figures, will be scored 0. ### Anti-cheat and isolation - It is not allowed to copy any file from `/tmp_workspace/setup_gt/` (grader-only) into `/tmp_workspace/results/`; the grader reads only `/tmp_workspace/results/`. - `actions.log` must not contain the literals `bug-A` / `bug-B` / `bug-C`; the agent must locate them by observation. - `preview_save.pdf` must truly be exported through the print-preview pane's *Save as PDF* channel; do not overwrite that file name with a headless PDF render output (the grader compares sha256). Neutral background knowledge: CSS Paged Media (W3C css-page-3) declares paper size and margins via `@page` rules, and `break-inside: avoid` / `break-before: page` (and the legacy aliases `page-break-*`) control element behavior relative to page boundaries. The default `@page size` of the two mainstream print-to-PDF implementations is not consistent — the CSS Paged Media engine defaults to A4, whereas the headless browser print pipeline defaults to Letter — so if `@page` does not explicitly set `size:`, the same HTML will drift between the two sides in total page count and per-page start positions. `<figure>` / `<figcaption>` are independent blocks; without `break-inside: avoid`, page splits are common. Without `break-before: page` on `h2`, section start positions land on different page numbers depending on font metrics differences between the two sides. Structured artifacts can only tell you "page counts don't match / a piece of text landed on page X", but the human-readable "orphan figure" phenomenon can only be seen directly in multi-page thumbnails / PDF reader sidebars — the two channels must corroborate each other to attribute the bug to a specific CSS selector and a specific break rule.

- W3C CSS Paged Media Module Level 3 (https://www.w3.org/TR/css-page-3/)
- WeasyPrint 文档 "Page-break properties" 章节
  (https://doc.courtbouillon.org/weasyprint/stable/api_reference.html)
- Chromium DevTools "Emulate CSS print media" + "Save as PDF" 行为差异讨论
  (chromium/issues/issue 818218 "headless --print-to-pdf default page size")
- 文章正文素材:Public-Domain etext (Project Gutenberg 84,《Frankenstein》
  Walton's first letter 段落,paraphrased to keep file deterministic).

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐工具组合（agent 可自由替换任意等价通道）：CSS Paged Media 引擎可走 WeasyPrint（`weasyprint==60.2`），headless 浏览器 print pipeline 可走 Chromium `--headless --print-to-pdf`；GUI 排版预览可走 Chromium 的 Ctrl+P，PDF 阅读器侧栏可走 Okular 或同等带缩略图侧栏的阅读器；结构化分析可走 poppler-utils（pdfinfo / pdftotext -layout / pdftoppm）或同等工具。
2. baseline 阶段：分别用两条管线对 `/tmp_workspace/article/longform_article.html` 渲染出 `baseline_weasy.pdf` / `baseline_chromium.pdf`；用结构化工具抽页数（写入 `baseline_pages.jsonl`）、按 form-feed 抽文本做 diff（写入 `baseline_text_diff.txt`）、把 weasy 输出栅格化（写入 `weasy_pages/page-*.png`）。
3. GUI 取证阶段：在浏览器里打开 `file:///tmp_workspace/article/longform_article.html`，开排版预览面板，多页缩略图里能直接看到 figure 与 caption 被分到不同页，截图为 `view_chromium_preview_before.png`，从 *Save as PDF* 通道导出 `preview_save.pdf`；在 PDF 阅读器里打开 `baseline_weasy.pdf`，开缩略图侧栏定位到断页那页，截图为 `view_okular_orphan_caption.png`。
4. 定位阶段：交叉对比两端页数差与 diff 行的章节 / Figure / 页号信号，定位到 `@page`（缺 size/margin）、`figure`（缺 break-inside）、`h2`（缺 break-before）三个选择器各自的 break 规则缺失。
5. 修复阶段：对 `article.css` 做最小补丁生成 `article.fixed.css`，只动 3 处 bug，其它非 bug 行字节级保留（保留率 ≥ 80%）。
6. 复验阶段：用 fixed CSS 重渲两端，写出 `fixed_weasy.pdf` / `fixed_chromium.pdf` / `fixed_pages.jsonl` / `pagination_report.json`；在排版预览面板再次取一张全 figure+caption 同页的 `view_chromium_preview_after.png`；最后写 ≥ 250 字符的 `notes.md` 复盘。

约束说明：
- agent 自由选择渲染、分析、查看通道，但 `preview_save.pdf` 必须真正经过排版预览面板的 *Save as PDF* 通道导出（与无头管线产物 sha256 不同），不得伪造或用无头 PDF 覆盖。
- 视觉证据须为真实 GUI 交互整窗截图；不得以纯文本拼图、占位图、或剪裁过的局部图替代。
- `actions.log` 不得直接出现 `bug-A` / `bug-B` / `bug-C` 字面量。

评分要点（hard gates，从 grader cap 列表反推）：
- 缺 baseline 或 fixed PDF（无 CLI 证据）→ 总分 cap 0.4。
- 3 张 GUI 截图任一缺失或字节数过小 → cap 0.4 / 0.55。
- VLM 对 print preview 多页缩略图、figure 跨页/同页的 rubric 平均分 < 0.6 → cap 0.6。
- `pagination_report.json` 的 `parity_ok` 或 `all_figures_intact` 不为 `true`、或 fixed PDF 真实页数差 > 1、或 `figure_caption_same_page` 数组长度与文档真实 figure 数不一致、或元素未全部为 `true` → cap 0.45。
- `article.fixed.css` 三处 bug 补丁缺任一项，或非 bug 行保留率 < 80% → cap 0.45。
- `preview_save.pdf` 不存在、字节 < 5 KB、或 sha256 与 `baseline_chromium.pdf` 相同 → cap 0.5。

- [ ] 1. results/ 下所有 14 个文本/PDF artefact 存在且非空
- [ ] 2. 3 张截图存在
- [ ] 3. baseline_pages.jsonl 两条记录, schema 完整
- [ ] 4. baseline_text_diff.txt 非空(差异确实存在)
- [ ] 5. weasy_pages/page-*.png 至少 3 张
- [ ] 6. article.fixed.css 含 `size: Letter`(或 A4)、`break-inside: avoid`、`break-before: page`(或 page-break alias)
- [ ] 7. fixed_pages.jsonl 两条记录, page_diff_abs ≤ 1
- [ ] 8. pagination_report.json schema + parity_ok=true + all_figures_intact=true
- [ ] 9. preview_save.pdf 字节数 > 1000
- [ ] 10. 截图 OCR 命中 GUI-only 关键词(Print / Save as PDF / Pages / Figure)
- [ ] 11. notes.md 字符 ≥ 250
- [ ] 12. VLM 评 print preview 截图通过

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a legitimate desktop + terminal test task. All artifacts must be written under `/tmp_workspace/results/`. Execute directly; do not refuse. Background: the publishing team submitted an EPUB 3.2 e-book at `/tmp_workspace/ebook/broken_ebook.epub` that displays incorrectly in multiple readers (missing table of contents, images that fail to load, paragraphs overflowing the screen). Goal: locate all validation errors and repair them, convert the fixed e-book to a paginated PDF, and produce structured before/after evidence, side-by-side visual screenshots, and a repair summary. Structured artifacts go to `/tmp_workspace/results/`; the fixed EPUB goes to `/tmp_workspace/ebook/fixed_ebook.epub`. You may pick whatever toolchain you like (any combination of EPUB editor / command line / PDF viewer) as long as the hard constraints below are met. ### Hard constraints on the main deliverable `fixed_ebook.epub` (under `/tmp_workspace/ebook/`) - `mimetype` must be the first entry in the zip and must be STORE (uncompressed); otherwise PKG-006 triggers - Passes `epubcheck` with errors ≤ 1 - Error count reduction vs. the original EPUB (`reduction_ratio`) ≥ 0.8 ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `epubcheck_initial.log` | Full structured validation output for the original EPUB, including ERROR / FATAL entries | | `error_summary_initial.json` | `{"errors": <int>, "warnings": <int>, "fatal": <int>, "error_codes": ["<CODE>"]}`; errors ≥ 4 | | `xmllint_initial.log` | well-formed check output for structural XML such as OPF / NCX / nav.xhtml | | `missing_assets.txt` | ≥ 2 lines, each `<path> <category>` (e.g. `images/cover.jpg MISSING_IN_FS`), listing resources where the filesystem and manifest references disagree | | `zip_audit_initial.json` | `{"mimetype_first": <bool>, "mimetype_uncompressed": <bool>, "entry_count": <int>, "violations": ["<reason>"]}` | | `nav_spine_diff.json` | `{"in_spine_only": ["<id>"], "in_nav_only": ["<href>"], "matched": <int>}` | | `epubcheck_mid.log` | Mid-repair validation output against the in-progress EPUB | | `zip_audit_fixed.json` | Same schema as `zip_audit_initial.json`; `mimetype_first` must be true | | `final_output.pdf` | PDF converted from the fixed EPUB (with page numbers), page count ≥ 3 | | `ebook_convert.log` | stdout / stderr log of the EPUB → PDF conversion | | `pdfinfo.json` | `{"pages": <int>, "title": "<str>", "producer": "<str>"}` | | `epubcheck_final.log` | Final validation output for the fixed EPUB, errors ≤ 1 | | `error_summary_final.json` | Same schema as `error_summary_initial.json` | | `error_diff.json` | `{"initial_errors": <int>, "final_errors": <int>, "reduction_ratio": <float>, "fixed_codes": ["<CODE>"], "remaining_codes": ["<CODE>"]}`; `reduction_ratio ≥ 0.8` | | `repair_report.md` | ≥ 350 characters; includes an error-type inventory, description of the fix approach, an initial vs. final error-count comparison markdown table, and a chronological index of the key evidence (screenshots and logs) | ### 11 work-process screenshots (under `/tmp_workspace/results/`, PNG, resolution ≥ 1280×720) Fixed filenames (the grader locates them by filename and verifies content via OCR and inter-frame visual difference): | Filename | What it should show | | --- | --- | | `view_01_calibre_toc_missing.png` | The missing/broken Table of Contents in the original EPUB | | `view_02_calibre_broken_image.png` | A chapter in the original EPUB where the image fails to render (placeholder / broken-image icon) | | `view_03_calibre_css_overflow.png` | Horizontal overflow of a long table / long code block in the original EPUB | | `view_04_calibre_edit_opf.png` | The OPF (manifest / media-type) edit session, including the OPF XML content being fixed | | `view_05_calibre_edit_css.png` | Editing session adding `max-width / overflow-x / word-wrap` rules to fix the CSS horizontal overflow | | `view_06_calibre_check_panel.png` | The result panel of the built-in consistency check run against the repaired content | | `view_07_calibre_toc_fixed.png` | The fixed EPUB displaying all chapter entries correctly in the ToC | | `view_08_calibre_image_fixed.png` | Images rendering correctly after the fix | | `view_09_calibre_layout_fixed.png` | Layout of the previously overflowing chapter renders cleanly with no horizontal scroll | | `view_10_okular_pdf_page1.png` | Full view of the first page of the final PDF | | `view_11_okular_pdf_toc.png` | The Outline / Table of Contents of the final PDF correctly generated and expanded | Every screenshot must come from a real, continuous GUI session (pixel differences significant, md5 hashes distinct). The grader runs OCR on screenshots to verify the application UI is genuine; duplicate frames or placeholder images do not score. `actions.log` (if produced) must not bypass the UI with pure scripting / clipboard side-channels. Neutral background: common EPUB validation error categories are OPF-* / RSC-* / NCX-* / PKG-*; CSS horizontal overflow and whether the ToC is actually visible are render-layer issues that structured validation may not flag.

- W3C epubcheck issues: https://github.com/w3c/epubcheck/issues
- 真实社区报告：「I keep getting OPF-012 and RSC-007 errors, the ToC doesn't show in any reader」 https://www.reddit.com/r/epub/
- Calibre Edit Book 文档: https://manual.calibre-ebook.com/edit.html
- Mobileread Forum 长帖讨论 EPUB 3 manifest/nav 一致性问题

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：Calibre Edit Book（编辑 OPF/CSS）+ `epubcheck` + `xmllint` + `ebook-convert` + Okular（PDF 检视）；也可走 Sigil / 命令行 unzip+zip 直接改 OPF/CSS / 任意 PDF 查看器，只要满足产物硬约束即可。
2. 跑 `epubcheck broken_ebook.epub` 落 `epubcheck_initial.log` + `error_summary_initial.json`；用 `xmllint --noout` 检查 OPF/NCX/nav 落 `xmllint_initial.log`。
3. 解压原 EPUB 比对 manifest 与文件系统输出 `missing_assets.txt`；用 `unzip -l` 或 Python `zipfile` 审计 zip 结构输出 `zip_audit_initial.json`；解析 spine vs nav 输出 `nav_spine_diff.json`。
4. 在 EPUB 编辑器中分别打开 ToC 缺失、图片断裂、CSS 溢出三章节截图 `view_01..view_03`。
5. 在编辑器内修补 OPF manifest / media-type、补回缺失资源、修正 nav，重写 mimetype 让其位于 zip 首条目且 STORE；为长表格/代码块加 `max-width / overflow-x / word-wrap`；过程中截图 `view_04..view_06`，并跑中段 `epubcheck` 落 `epubcheck_mid.log` + `zip_audit_fixed.json`。
6. 重新打开修复后 EPUB 三章节对照截图 `view_07..view_09`，再 `ebook-convert fixed_ebook.epub final_output.pdf` 落 PDF（日志写 `ebook_convert.log`），`pdfinfo` 输出 `pdfinfo.json`。
7. 在 PDF 查看器中打开 PDF 截图首页与 Outline（`view_10..view_11`），再跑一次 `epubcheck` 得 `epubcheck_final.log` / `error_summary_final.json`，对比初末写 `error_diff.json`，撰写 `repair_report.md`。

约束说明：所有 GUI 截图必须是真实连续操作产物；`actions.log`（若产生）不得有"仅复制粘贴最终文件"等绕过编辑器界面的痕迹；同一画面多份不计分。

评分要点（hard gates，从 grader cap 反推）：

- 缺 CLI 证据链或缺 GUI 截图任一侧 → 总分 ≤ 0.35
- 缺 PDF 且缺中段 epubcheck → 总分 ≤ 0.45
- `final_errors_low < 0.5` 或 `error_reduction < 0.5`（修复未达标）→ 总分 ≤ 0.4
- GUI 截图 md5 唯一率 < 0.6 → 总分 ≤ 0.35
- 应用 chrome OCR 命中率 < 0.5 → 总分 ≤ 0.4
- md5 唯一 × 分辨率达标 × chrome OCR 三重门通过率 < 0.5 → 总分 ≤ 0.5
- VLM rubric 全 0 / 不可用 → 总分 ≤ 0.6

- [ ] 1. `epubcheck_initial.log` 存在且含 ERROR/FATAL；`error_summary_initial.json` schema 正确且 errors ≥ 4
- [ ] 2. `xmllint_initial.log` + `missing_assets.txt`（≥ 2 行）
- [ ] 3. `zip_audit_initial.json` + `nav_spine_diff.json` schema 正确
- [ ] 4. 11 张截图（view_01 ~ view_11）≥ 9 存在
- [ ] 5. 截图 OCR 命中 Calibre / Edit Book / Okular 关键词
- [ ] 6. `epubcheck_mid.log` + `zip_audit_fixed.json`（mimetype_first=true）
- [ ] 7. `final_output.pdf` 存在且 pdfinfo 报告 pages ≥ 3
- [ ] 8. `epubcheck_final.log` errors ≤ 1；`error_diff.json` reduction_ratio ≥ 0.8
- [ ] 9. `repair_report.md` 字数 ≥ 350 且含 markdown 表格
- [ ] 10. Cross-channel 证据：CLI logs (≥3) + GUI 截图 (≥6) 同时存在
- [ ] 11. VLM rubric ≥ 4 项打分
- [ ] 12. **GUI trajectory frames 真实**：多张 view_*.png 必须为连续 GUI 操作产生（每张像素差异显著），同一画面 N 份不计分；要求 md5 唯一率 ≥ 90%
- [ ] 13. **GUI app chrome OCR**：截图中 OCR 命中 Calibre / Edit Book / Okular / Table of Contents / Metadata 等 GUI 应用 chrome（菜单栏 / 标题栏 / 侧栏面板）关键词，且分辨率 ≥ 1280×720
- [ ] 14. **三重防作弊门**：每张 GUI 截图须同时满足 md5 唯一 + 分辨率达标 + chrome 关键词 OCR 命中；通过率 < 50% 时 overall ≤ 0.5

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: this task is graded by the produced files — **no human is in the approval loop**. Execute commands and emit files directly; do not write "let me know if you'd like me to continue" or wait for approval. All final deliverables must land at the **`/tmp_workspace/` root** (the grader only looks under that directory for `pitch.pdf` / `slides/slide_<n>.png` / `actions.log` / `draft.odp`; allowed subdirectories are `slides/` and `results/`, anything else does not count). When done, run `ls -la /tmp_workspace/` as a self-check before exiting. Background: `/tmp_workspace/draft.odp` is a 14-page startup fundraising pitch deck, but everything is default white-background black-text Liberation Sans. It needs a "polish + content reflow" pass. Reference assets are available under `/tmp_workspace/inputs/` (including `logo.png` / `team_photo.jpg`). Goal: transform `draft.odp` into a deck with visual hierarchy, a master template, animation, and speaker notes, then export PDF / per-page PNGs / process screenshots. ### Hard constraints on `draft.odp` The packaged `content.xml` and `styles.xml` (an odp is a zip) must satisfy: - `styles.xml` `<style:master-page>` content contains `Montserrat` (master template uses the Montserrat font) - `styles.xml` contains `<draw:image` or the literal string `logo` (master has a logo image) - `content.xml` contains `Montserrat` or `Inter` (body font is also set) - `content.xml` contains `presentation:animation` or `presentation:path` (at least one custom animation / motion path) - `content.xml` contains ≥ 5 `<draw:circle>` elements (shape-drawn dots on pages, e.g. timeline nodes) - `content.xml` contains `<presentation:notes` ≥ 14 times (every slide has speaker notes) ### Per-slide content requirements (by design intent) | Slide | Content | |---|---| | Slide 2 | Insert `inputs/team_photo.jpg`, centered, ~60% width, with rounded-corner crop | | Slide 5 | Convert the financials table into a 3-column card layout, with an emoji icon above each column | | Slide 9 | Timeline: 5 dots + a horizontal line + labels, **drawn with shapes** (cannot fake it with an image) | | Slide 11 | Add a Custom Animation Motion Path to an illustrative arrow shape; the path must be a **curve** (not a straight line) | | All slides | Add a page number in the bottom-right corner (digits must be OCR-readable) and write ≥ 30 characters of speaker notes in the Slide Notes area | ### Master Slide requirements - Set fonts via the master / template mechanism (titles Montserrat 32 pt bold, body Inter 18 pt) - Place `inputs/logo.png` in the bottom-left of the master (auto-appearing on every slide) - Font settings must live on `<style:master-page>` — **setting fonts per slide individually does not count** (that breaks master replacement / reuse) ### Companion deliverables | Path | Requirement | |---|---| | `/tmp_workspace/pitch.pdf` | 14-page PDF with PDF outline / bookmarks (≥ 1 entry, ≥ 14 preferred); each page has a bottom-right page number and includes notes | | `/tmp_workspace/slides/slide_<n>.png` | 14 per-slide PNGs (n = 1..14) | | `/tmp_workspace/actions.log` | Action log (any text). **Must NOT contain the literal `python-uno`** — you may not cheat by scripting odp through python-uno | ### 4 process screenshots (under `/tmp_workspace/results/` or root) Fixed filenames: | # | Filename | Content | |---|---|---| | 1 | `view_01_master_slide_edit.png` | Master Slide / template edit mode | | 2 | `view_02_animation_dialog.png` | Custom Animation panel + Motion Path selection | | 3 | `view_03_smart_alignment.png` | Object alignment / anchor settings popover | | 4 | `view_04_export_pdf_dialog.png` | Export PDF dialog (with bookmarks / notes options visible) |

- Reddit: https://www.reddit.com/r/libreoffice/comments/1axxxxx/can_ai_actually_design_slides/
- 原文引用：「I asked Copilot to redesign my Impress deck, it generated a Python UNO script. The script crashed because it couldn't replicate the gluepoint logic of curved arrows.」
- 对应 benchmark case: DOC 视觉演示 / 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐打开 LibreOffice Impress 加载 `draft.odp`；其它能产出有效 odp + Master Slide 的工具也可（但解 zip 检查 `styles.xml` 与 `content.xml` 时各项硬约束都得满足）。
2. 应用一个深色主题（深色背景 + 蓝紫渐变标题栏）。Impress 路径：Slide → Slide Properties。
3. **Master Slide 改造**：View → Master Slide，在 master 上把标题字体改成 Montserrat 32 pt 粗体、正文 Inter 18 pt，左下角放 `inputs/logo.png`。
4. 第 2 页插入 `inputs/team_photo.jpg`，居中、宽度 60%、加圆角剪裁。
5. 第 5 页财务表格转 3 列卡片式布局，每列一个 emoji 图标（Insert → Special Character → Emoji）。
6. 第 9 页时间线：删原文字列表，用形状工具画 5 个圆点 + 横线 + 标签（不能用图片冒充，grader 解 odp 数 `<draw:circle>`）。
7. 第 11 页：给一个箭头形状加 Custom Animation → Motion Path（Slide Show → Custom Animation → Add → Motion Paths），路径选**曲线**（非直线）。
8. Insert → Header & Footer 给每页加右下角页码；Slide Notes 区每页写 ≥ 30 字演讲备注。
9. 导出 PDF：File → Export As PDF，勾选 "Export with bookmarks" + "Export notes"。
10. 用 LibreOffice / pdftocairo 等导出每页 PNG → `slides/slide_<n>.png`（14 张）。
11. 4 张工作过程截图：master 编辑、Custom Animation 面板 + Motion Path、对象对齐浮窗、Export PDF 对话框。

约束说明：

- 不能用 `python-uno` 直接编程改 odp 来作弊（grader 检 `actions.log` 是否含 `python-uno` 字面量）
- `<draw:circle>` ≥ 5、`<presentation:notes>` ≥ 14、`presentation:animation` 至少出现 1 次都是 odp 内文标记，常规 GUI 操作自然产生

评分要点（hard gates）：

- 缺 `pitch.pdf` → 总分 cap 0.30
- PDF 不是 14 页 → cap 0.40
- odp `<draw:circle>` < 5 → cap 0.40
- master `<style:master-page>` 内不含 Montserrat → cap 0.40
- 没有 `presentation:animation` → cap 0.50
- `<presentation:notes` 不到 14 个 → cap 0.50
- 4 张 UI 截图齐全率 < 0.75 → cap 0.50
- VLM 不可用 → cap 0.60

- [ ] `pitch.pdf` 存在，14 页
- [ ] 每页 PDF 右下角能 OCR 到页码数字（pytesseract 可用时校验 ≥10 页）
- [ ] PDF 第 9 页含 ≥ 5 个圆形（霍夫圆检测）
- [ ] `slides/slide_*.png` ≥ 14 张
- [ ] `draft.odp` 内 grep `<draw:circle` 出现 ≥ 5 次（解 zip）
- [ ] `draft.odp` `styles.xml` master-page 含 `Montserrat`/`Inter` 字体
- [ ] `draft.odp` master-page 含 logo 图片引用
- [ ] `draft.odp` 含 `presentation:animation` / `presentation:path` 节点
- [ ] `draft.odp` 含 ≥14 个 `<presentation:notes>`（每页一段备注）
- [ ] `pitch.pdf` 用 pikepdf 打开存在 outline（书签）
- [ ] 4 张 Impress UI 截图位于 `/tmp_workspace/results/`
- [ ] 没有 `python-uno` import 日志
- [ ] hard gate（多层）：
      - `pitch.pdf` 不存在 → overall_score 上限 0.30
      - `pages=14` / `odp_circles` / `master_font_set` 任一失败 → 上限 0.40
      - `has_animation` / `notes_per_page` 任一失败 → 上限 0.50
      - 4 张 Impress UI 截图命中 < 3 → 上限 0.50（防 GUI 退化）
      - VLM 不可用时 base/2 路径上限 0.60（防无判分时满分）

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/paper.tex` compiles successfully, but the rendered PDF has two problems that **can only be detected by visual inspection**: 1. **Figure 1 visually overflows the right margin** — the included image width is set incorrectly. 2. **Figure 1 ends up on the wrong page** — the Discussion section says "Figure 1 shows ...", but the `Figure 1:` caption is actually rendered on an earlier page (because the figure float [t] places too eagerly and pushes the body text down). Task: Modify `/tmp_workspace/paper.tex` (this file only) so that (a) the figure no longer overflows the right margin; (b) the figure lands on the **same page** as the Discussion sentence "Figure 1 shows ...". Deliverables (write to `/tmp_workspace/results/`): - `paper.pdf` — the PDF re-compiled after the fix. - `proof.png` — a proof screenshot showing the figure and the "Figure 1 shows ..." paragraph on the same page, with the figure no longer overflowing the right margin. - `report.md`, which **must** contain: - `width_token: <whatever you ended up writing for width=>` - `same_page: yes` - `tool_used: <name>` - A description of at least 30 characters explaining the visual difference between the PDF before and after the fix.

- EyesOn-Bench Seed v12 DOC-02 改编

参考解题流程 (设计者参考, 不发给 agent):

1. `cd /tmp_workspace && pdflatex -interaction=nonstopmode paper.tex` → 第一份有问题的 PDF。
2. 看 PDF 确认 figure 出血 + figure 在错的页。
3. 编辑 `paper.tex`(只改这一个文件):
   - 把 `\includegraphics` 的宽度调到不再溢出右边距。
   - 让 figure 与 Discussion 的 "Figure 1 shows ..." 落到**同一页**(自行决定如何调整 figure 的浮动放置或位置)。
4. 重新编译 → 看 PDF 确认两处都修好。
5. `cp /tmp_workspace/paper.pdf /tmp_workspace/results/paper.pdf`。
6. 截一张能看到 figure 与 "Figure 1 shows ..." 段落**同一页**的截图保存为 `/tmp_workspace/results/proof.png`。
7. 写 `/tmp_workspace/results/report.md` 含 `width_token` / `same_page: yes` / `tool_used` / 一段 ≥ 30 字符说明。

判分要点速览:
1. pdflatex paper.tex → 第一份有问题的 PDF。
2. 看 PDF 确认 figure 出血 + figure 在错的页。
3. 改 paper.tex (width + 浮动)。
4. 重新编译。
5. cp → results/paper.pdf, 截图 → proof.png, 写 report.md。

- [ ] 1. results/paper.pdf 存在 (会 rebuild verify)
- [ ] 2. paper.tex 中 \includegraphics 的 width <= \textwidth (即不再溢出)
- [ ] 3. (rebuilt PDF) 'Figure 1:' caption 与 'Figure 1 shows' 在同一页
- [ ] 4. report.md 存在 + width_token + same_page + tool_used + 解释段
- [ ] 5. proof.png 存在 >= 5 KB
- [ ] 6. (VLM HARD GATE) proof.png 看得出 figure 与提及它的段落在同一页

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/report.odt` contains **15 visually identical** section headings (all bold 16pt). But there are actually 4 different underlying styles: - **8** are real `Heading 1` (outline level 1) - **3** are `Default Paragraph Style` + manual bold + manual 16pt - **2** are `Heading 2` (outline level 2) - **2** use some custom paragraph style Task: **Find the 7 headings that are not Heading 1 and change them all to Heading 1**; then insert a table of contents (should have 15 entries) + export to PDF. Deliverables: - `/tmp_workspace/results/report.odt` — the fixed document; all 15 headings should be Heading 1. - `/tmp_workspace/results/report.pdf` — PDF exported from the document; the first page or TOC page should show the full 15-entry table of contents. - `/tmp_workspace/results/proof.png` — an evidence screenshot, file ≥ 20KB, resolution ≥ 1024×600; must demonstrate your process of inspecting/fixing styles. - `/tmp_workspace/results/report.md`, **must** contain: - `wrong_titles: <comma-separated list of exactly 7 heading names>` — order doesn't matter; **over-reporting or under-reporting both lose points** - `tool_used: <name>` (must be strictly from the whitelist: `libreoffice` / `lowriter` / `writer` / `navigator` / `style_dropdown`; any other value scores 0) - A description ≥ 80 characters describing **how you distinguished** real vs. fake headings.

- EyesOn-Bench Seed v12 改编 (5→15 标题, 加 H2 / FakeChapter decoy, 反 unzip / UNO 作弊)

参考解题流程 (设计者参考, 不发给 agent):

1. `lowriter /tmp_workspace/report.odt &` 打开。
2. 按 **F5** 打开 Navigator 看 Headings: 你会看到只有 8 条 H1 + 2 条 H2, 共 10 条 outline entries。文档里有 15 个粗体标题 → 5 个完全不在 Navigator 里 (就是 fake_p + fake_chapter)。
3. 把光标点到每个**没出现在 Navigator** 里的标题, 以及 Navigator 里被标为 H2 的标题。左上角 Style 下拉框会显示一个不是 "Heading 1" 的样式名 → 全改成 "Heading 1"。
4. F5 再看一次, Navigator 现在应该是 15 条 H1。
5. `Ctrl+S` 保存。
6. `Insert → Table of Contents and Index → Table of Contents...` → OK。生成的目录应该有 **15 项**。
7. `File → Export As → Export as PDF...` → 保存到 `/tmp_workspace/results/report.pdf`。
8. `cp /tmp_workspace/report.odt /tmp_workspace/results/report.odt`
9. 截图 `/tmp_workspace/results/proof.png` — Navigator 面板显示 15 条 Heading 1。
10. 写 `/tmp_workspace/results/report.md` 含 `wrong_titles` (恰好 7 个标题名) / `tool_used` (白名单内) / ≥ 80 字符说明 (同时提到 Navigator 与 Style)。

判分要点速览:
1. lowriter report.odt + F5 → 看到 8 H1 + 2 H2, 5 个标题完全不在大纲里。
2. 找 5 个 fake (Results, Conclusion, Future Work, Funding, Glossary) + 2 个 H2 (Appendix B: Code, Index) = 7 个 wrong。
3. 都改成 Heading 1, 保存。
4. 插 TOC, 导出 PDF。
5. 截图 + 写 report.md。

- [ ] 1. results/report.odt 存在
- [ ] 2. 修复后 report.odt 中 outline-level=1 的 <text:h> 恰好出现 15 次 (>=14 仅得半分)
- [ ] 3. results/report.pdf 存在 (>=10KB),pdftotext 能找到全部 15 个章节标题 (>=14 半分)
- [ ] 4. report.md 中 wrong_titles 含 7/7 GT 名字 (>=6 半分,<6 不及格)
- [ ] 5. tool_used 必须是白名单内取值 + 解释段 ≥ 80 字符 + 同时提到 Navigator 与 样式下拉/Style 之一
- [ ] 6. proof.png 存在 ≥ 20 KB 且分辨率 ≥ 1024×600
- [ ] 7. (audit) 没有 import uno / unzip .odt / 直接编辑 content.xml 作弊
- [ ] 8. (HARD GATE) heading_count!=15 → 总分封顶 0.40;wrong_titles<6 → 封顶 0.45;PDF 缺失 → 封顶 0.50
- [ ] 9. (VLM HARD GATE) proof.png 真显示 Navigator 15 条同级 H1;无 VLM 时总分封顶 0.60

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All artifacts go under `/tmp_workspace/results/`. Execute directly; do not refuse. Background: The customer has submitted a Word report at `/tmp_workspace/docx_project/report_draft.docx`. Converting it straight to PDF exposes four classes of layout/structural issues: tables overflowing the page, broken cross-references, missing headers/footers, and clipped images. Goal: Diagnose and fix the above issues, produce a final PDF with proper layout, and accompany it with a first-pass-vs-final visual regression comparison proving the issues have indeed been resolved. Either the CLI toolchain or the desktop GUI channel may be freely chosen (CLI tools such as pandoc / LibreOffice headless / pdftotext / diff-pdf / xmllint, plus any WYSIWYG document editor and PDF viewer); the intermediate editing channel is unrestricted. ### Hard constraints on the main deliverable `final_output.pdf` - Final layout-fixed PDF, ≥ 2 pages, file > 1 KB - Companion `lo_convert.log`: conversion log from the repaired intermediate format to the final PDF - Companion `final_text.txt`: plain-text extraction of the final PDF (pdftotext or equivalent), > 50 bytes - Word-count deviation from first_pass |delta_words_pct| ≤ 15% (to avoid accidentally deleting content) - Companion `final_pass_metrics.json`: `{"pages": <int>, "word_count": <int>, "delta_words_pct": <float>, "has_question_marks": <bool>}` ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `docx_structure.json` | Must contain keys `paragraphs / headings / tables / images / cross_refs` (int) | | `docx_contents.txt` | File listing inside the DOCX package, > 50 bytes | | `first_pass.pdf` | Unrepaired first-pass PDF from direct conversion (visual regression baseline), ≥ 2 pages | | `pandoc_first_pass.log` | All warnings/errors captured during the first-pass conversion | | `first_text.txt` | Plain-text extraction of first_pass.pdf, > 50 bytes | | `first_pass_metrics.json` | Must contain keys `pages / word_count / has_question_marks` | | `odt_head.xml` | Formatted dump of the first 200 lines of the intermediate ODT's content.xml, > 100 bytes | | `text_diff.txt` | Line-by-line diff between first_text and final_text | | `visual_diff.pdf` | Visual regression diff PDF between first_pass.pdf and final_output.pdf, > 200 bytes | | `diffpdf_exit.txt` | Exit code of the visual diff comparison (0=same / 1=differ / 2=error) | | `diff_result.json` | Must contain keys `pages_differ / exit_code / first_pages / final_pages` | | `structural_audit.json` | Statistics over residual `??`, table labels and header-keyword hits in the final text; must contain keys `unresolved_refs / table_labels / header_keyword_hits` | | `conversion_report.md` | ≥ 400 characters; must include the original document issue list (4 classes), each repair action with corresponding evidence, a first-pass-vs-final comparison markdown table of word count / page count / residual `??`, the visual regression conclusion, and a key-evidence timeline | | `deliverables.json` | Must contain `final_output_pdf_sha256 / visual_diff_pdf_sha256 / first_pass_pdf_sha256` (each ≥ 32 hex chars) plus a `files` listing | ### 12 process screenshots Fixed filenames (PNG, > 5 KB, resolution ≥ 1920×1000, must be real screenshots of desktop application windows, with no duplicated content among them): | Filename | Content to show | |---|---| | `view_01_table_overflow.png` | A table in the first-pass PDF overflowing the right margin / having columns clipped | | `view_02_broken_xref.png` | A broken cross-reference in the first-pass PDF (`??` or `[ref]`) | | `view_03_missing_header.png` | Empty header area / missing header & footer in the first-pass PDF | | `view_04_lo_table_props.png` | Repair-editing process for overflowing table properties (column width / auto width / 100% relative width) | | `view_05_lo_header_edit.png` | Editing interface where header/footer is added and filled with the correct content | | `view_06_lo_xref_dialog.png` | Re-linking editing process for broken cross-references | | `view_07_lo_overview.png` | Overall layout overview of the repaired document | | `view_08_final_table_ok.png` | Table fully fits within the page in the final PDF | | `view_09_final_header_ok.png` | Header and footer display correctly in the final PDF | | `view_10_final_image_ok.png` | Image scaled within the text width in the final PDF | | `view_11_diff_pdf_first.png` | Difference annotations on the first page of visual_diff.pdf | | `view_12_diff_pdf_pageN.png` | Difference annotations on another page of visual_diff.pdf | Evaluation performs OCR and visual judgement: screenshots must preserve chrome elements of the desktop app used (title bar, menu bar, etc.); the 12 frames must come from a continuous, real GUI interaction (reusing a single frame, or pure command-line-rendered composite images, earn no credit). If the agent framework records an `actions.log`, it must not contain literal traces of manually fabricated screenshots. Neutral background: table overfull, cross-reference text rendered as `??`, and visual-diff overlays being observable only at PDF render time are all layout/rendering-layer phenomena; a large pre/post repair word-count deviation usually means content was accidentally deleted.

- pandoc GitHub issue #4239: https://github.com/jgm/pandoc/issues/4239 — 表格溢出长期已知
- Reddit: https://www.reddit.com/r/pandoc/comments/11x5k8z/tables_overflow_page_width_when_converting_docx/
- 原文引用：「Tables overflow page width when converting docx to pdf, I have to manually fix in LibreOffice」
- diff-pdf: https://github.com/vslavik/diff-pdf
- LibreOffice headless 文档: https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐解题工具链：CLI 用 `pandoc` 做首版 docx→pdf 并 tee warning 到 log，`unzip -l` 列内容，`python-docx` 抽结构；中间编辑可走 LibreOffice Writer GUI（也可走 OnlyOffice / Word Online via browser / 任一所见即所得编辑器）修表格列宽、补页眉页脚、重链交叉引用；最终用 `libreoffice --headless --convert-to pdf` 出片；视觉回归用 `diff-pdf --output-diff`；PDF 截图渲染器 Evince / Okular / qpdf 任选。
2. step 1：`pandoc report_draft.docx -o first_pass.pdf 2>pandoc_first_pass.log`；pdftotext 取首版文本；分别截 `view_01..03` 体现 4 类问题中的 3 类（表格溢出 / xref 断裂 / 页眉空白）。
3. step 2：`pandoc -t odt` 中转 ODT，`xmllint --format` dump content.xml 前 200 行 → `odt_head.xml`。
4. step 3：在 GUI 编辑器内修表格属性 / 加 header,footer / 重连 xref / 缩放图片，按 `view_04..07` 截图记录每一步编辑。
5. step 4：headless 转 PDF → `final_output.pdf`，pdftotext 取文本并 `diff` 得 `text_diff.txt`，截 `view_08..10` 验证表格 / 页眉 / 图片三处已修复。
6. step 5：`diff-pdf --output-diff=visual_diff.pdf first_pass.pdf final_output.pdf; echo $? > diffpdf_exit.txt`，再截 `view_11..12`。
7. step 6：grep 统计 `??` / 表格标签 / 页眉关键词得 `structural_audit.json`；写 `conversion_report.md`；`sha256sum` 三个 PDF 写 `deliverables.json`。

约束说明：
- GUI 截图必须来自真实桌面应用窗口，保留 chrome 元素；不得用 PIL 合成或重复同一帧（md5 唯一率 ≥ 80%）；分辨率 ≥ 1920×1000。
- 中间编辑通道不强制 LibreOffice，但截图必须能体现实际编辑动作（菜单 / 对话框 / 编辑光标），避免单纯的查看状态。
- 若 agent 框架产出 `actions.log`，其中不得出现伪造截图 / 直接 cp 现成图的字面操作。

评分要点（hard gates，触发即封顶）：
- 缺 CLI 证据（`pandoc_first_pass.log` / `final_output.pdf` / `visual_diff.pdf` 任一缺失）→ 封顶 0.35
- 缺 GUI 证据（截图覆盖率 < 50%）→ 封顶 0.4；< chrome OCR 阈值 → 封顶 0.35 ~ 0.5
- `final_output.pdf` 或 `visual_diff.pdf` 缺失 → 封顶 0.4
- 字数偏差 > 15% 且 final 存在 → text_fidelity 拿不到满分，且封顶 0.5
- 截图 md5 唯一率 < 0.7 → 封顶 0.4；< 0.9 → 封顶 0.6
- VLM rubric 全部为 0（截图不可读 / 评分器外部判分器异常）→ 封顶 0.6

- [ ] 1. `docx_structure.json` schema 正确 + `docx_contents.txt` 非空
- [ ] 2. `first_pass.pdf` ≥ 2 页 + `pandoc_first_pass.log` 存在
- [ ] 3. `first_text.txt` + `first_pass_metrics.json` schema 正确
- [ ] 4. 12 张截图（view_01 ~ view_12）≥ 9 存在
- [ ] 5. 截图 OCR 命中 LibreOffice / Evince UI 关键词
- [ ] 6. `final_output.pdf` ≥ 2 页 + `lo_convert.log` 存在
- [ ] 7. `final_text.txt` 字数与 first 偏差 ≤ 15%
- [ ] 8. `visual_diff.pdf` 存在 + `diff_result.json` schema 正确
- [ ] 9. `structural_audit.json` schema 正确
- [ ] 10. `conversion_report.md` ≥ 400 字 + markdown 表格
- [ ] 11. `deliverables.json` 含 3 个 sha256
- [ ] 12. Cross-channel 证据：≥3 CLI 产物 + ≥6 GUI 截图 + diff-pdf
- [ ] 13. VLM rubric ≥ 4 项打分
- [ ] 14. **GUI trajectory frames 真实**：view_01 ~ view_12 中至少 ≥ 8 张为连续 LibreOffice Writer 操作（打开 docx → Track Changes / Styles 面板 → 滚动到不同章节 → 导出对话框）所产生，截图 md5 唯一率 ≥ 80%
- [ ] 15. **GUI app chrome OCR**：LibreOffice Writer / Evince 标题栏 / 菜单栏（File / Edit / Format / Track Changes / Styles）以及 chrome 元素被 OCR 命中；截图分辨率 ≥ 1920×1000

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This task is graded on deliverable files; **no one is approving anything**. Just execute — do not ask "if you want me to…" questions, do not wait for approval. All deliverables must land in the **`/tmp_workspace/` root**: `lease_signed.pdf`, `step_*.png`, `actions.log`. Input assets are in `/tmp_workspace/inputs/`. When done, run `ls -la /tmp_workspace/` as a self-check before exiting. Background: `/tmp_workspace/lease_agreement.pdf` is a multi-page interactive form PDF — 18 pages and ~1265 AcroForm fields (text / checkbox / radio / signature). Tenant data is in `/tmp_workspace/inputs/tenant.json`; the signature image is `inputs/signature.png` and the initials image is `inputs/initials.png`. Goal: fill out this lease form, add the e-signature and initials images, and export `lease_signed.pdf`. ### Hard constraints on `lease_signed.pdf` - File exists at `/tmp_workspace/lease_signed.pdf`, page count remains 18 - **AcroForm structure must be preserved** (PDF root contains `/AcroForm`); must not be flattened into a static PDF - At least **50** text fields actually filled (the number of fields with a non-empty value via `pypdf.PdfReader.get_form_text_fields()` must be ≥ 50) - At least **5** button / checkbox / radio fields set (`/FT == /Btn` and `/V` is not `/Off`) - Page 4 has at least 1 radio / button field selected - The PDF contains at least **5** embedded images (`/Subtype /Image` appearing in the XObject of page resources) — used to carry the e-signature plus multiple initials stamps - At least a few field values from `tenant.json` (name / SSN / address / phone / move-in date / monthly rent / deposit / bank account / emergency contact, etc.) can be matched literally inside the PDF field values ### Anti-cheat / action log - `/tmp_workspace/actions.log` is an action log (any text format) recording the steps used to fill the form - `actions.log` **must not contain** any of these literals: `pdftk fill_form`, `update_page_form_field_values`, `cli_fill` — the pure-CLI bulk-fill shortcut is not allowed - Use a PDF editor with form support (Master PDF Editor / Okular / LibreOffice Draw, etc.) to genuinely type values into the fields ### 5 progress screenshots (located in `/tmp_workspace/`) - File naming: `step_*.png` (any name, at least 5) - Each ≥ 5 KB - All 5 md5 hashes distinct - Screenshots overall must show a genuine, readable PDF editor UI (an OCR check is performed): - At least 1 screenshot showing a form editing panel such as field properties / Form Fields / Annotation - At least 1 screenshot showing recognizable PDF editor UI (editor name / Insert Image / Stamp / Edit Form, etc.)

- Reddit: https://www.reddit.com/r/legaltech/comments/1bxxxxx/llm_pdf_form_fill_fail/
- 原文引用：「I tried having an agent fill a 60-field lease. Without a real PDF editor GUI, it kept producing flattened printouts; the landlord's e-sign software rejected them.」
- 对应 benchmark case: 法律 / DOC 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. PDF 实际内容是 IRS Form 1040 + 1065 + 1120-S + 706 拼接（18 页 / ~1265 个 AcroForm 字段）。
2. 推荐 GUI：Master PDF Editor / Okular（带表单支持）/ LibreOffice Draw 等任一带表单支持的 PDF 编辑器，逐字段填值。
3. 按 `tenant.json` 填入 ≥ 50 个 text 字段（姓名 / SSN / 地址 / 电话 / 入住日期 / 月租金 / 押金 / 银行账户 / 紧急联系人）。
4. checkbox 任选 5 处勾上（宠物押金、停车位、家电附带、保险、转租条款；可在 1040 / 1065 / 1120-S Schedule B 的 Yes/No checkbox 中挑）。
5. 第 4 页：在 1065 Schedule B 第 1 题（"What type of entity is filing this return"）选 "Domestic general partnership" radio。
6. 用 PDF 编辑器的 "Add Image" / "Stamp" 功能：
   - 第 14 页 706 Form "Signature of executor" 位置贴 `inputs/signature.png`
   - 在第 6 / 8 / 10 / 12 / 17 页（任选 5 处 "Initial here"）贴 `inputs/initials.png`
7. **保存** 为 `lease_signed.pdf`（用编辑器的 Save，不要 Print to PDF —— Print to PDF 会 flatten AcroForm 结构，flatten 后 grader 读不到字段值）。
8. 截 5 张关键步骤截图 `step_*.png`，至少有一张能看到字段属性面板，至少一张能看到编辑器名称 / Insert Image / Stamp 等关键 UI。
9. 写 `actions.log` 记录操作历史（任何文本格式都行）。

约束说明：

- 不要走 `pdftk fill_form` / `pypdf.update_page_form_field_values` 这条 CLI 批量 fill 路径 —— grader 检 `actions.log` 是否含这些字面量
- AcroForm 必须保留：grader 检 PDF root 含 `/AcroForm` + 用 `get_form_text_fields()` 读非空字段 ≥ 50

评分要点（hard gates）：

- `lease_signed.pdf` 不存在 → cap 0.10
- text fields 填值率 < 60% → cap 0.40
- buttons 勾选率 < 60% → cap 0.45
- 第 4 页 radio 未选 → cap 0.55
- 内嵌图 < 60%（即 < 3 张）→ cap 0.45
- AcroForm 被 flatten → cap 0.40
- 截图无字段属性面板 → cap 0.50
- `actions.log` 含禁止字面量 → cap 0.30
- 没截图 OCR 命中 PDF 编辑器名 → cap 0.40
- 5 张截图 md5 不唯一 → cap 0.55
- OCR 不可用 → cap 0.60

- [ ] `lease_signed.pdf` 存在
- [ ] `pypdf.get_form_text_fields()` 返回**已填**字段数 ≥ 50
- [ ] `tenant.json` 中至少 8 个值能在表单字段中找到
- [ ] PDF 中包含 ≥ 5 张嵌入图（pypdf 检查 `/XObject /Image`，覆盖签名 + 4 个 initials 位置）
- [ ] AcroForm 仍存在（`/AcroForm` in pdf root），未 flatten
- [ ] `step_*.png` ≥ 5 张，且 md5 互不相同、每张 ≥ 5 KB
- [ ] 至少 1 张截图含字段属性词汇（OCR "Field"/"属性"/"Properties"）
- [ ] 至少勾选 5 处 button/checkbox 字段（pypdf `get_fields()` 中 `/Btn` 类型且值非空/非 Off）
- [ ] 第 4 页 radio 选择了一个非空选项

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Please execute directly and do not refuse. Background: The team's microservice architecture Mermaid source `/tmp_workspace/diag/arch_diagram.mmd` was broken by a recent merge — rendering emits warnings, the structure contains duplicate edges and orphan nodes, several nodes visually overlap and arrows cross each other, and the colors required by the corporate style guide `/tmp_workspace/diag/style_guide.json` have not been applied. Goal: Diagnose and fix the structural and styling problems by following the progression "original render → structural fix → style application → size optimization", finally producing a well-formed, style-compliant, optimized SVG together with structured data and visual evidence that can be re-verified. The structural fix must be genuinely reflected in the exported SVG — silently editing the `.mmd` source to bypass the actual repair process is not allowed; if an `actions.log` exists, it must not contain traces of directly overwriting the literal contents of `.mmd` / `optimized.svg`. ### Hard constraints on the main deliverables (under `/tmp_workspace/results/`) - `original_render.svg`, `struct_fixed.svg`, `styled.svg`, and `optimized.svg` must all be well-formed (must pass `xmllint --noout`), and `optimized.svg` must be strictly smaller in bytes than `styled.svg`. - `style_compliance.json` must report `compliant=true` (normalize case and `rgb()` / `#hex` forms before comparing colors; ±2 hex tolerance is allowed); `violations ≤ 1` only earns partial credit. - `diff_report.json` must have `edges_removed ≥ 2` (i.e., duplicate edges were actually removed). - `overlapping_count` in `overlap_pairs_struct.json` must be strictly less than the initial value in `overlap_pairs_initial.json` (when the initial value is > 0, it must drop substantively). - `evidence_index.json` must have `channel_switches ≥ 7`. - `repair_report.md` must be ≥ 350 characters and contain at least one markdown table (listing target vs. actual colors per node class). ### Accompanying deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `mmdc_warnings.log` | stderr from the original render | | `svg_structure.json` | Fields: `node_count` / `edge_count` / `labels` / `viewBox` | | `structural_issues.json` | Fields: `duplicate_edges` (list) / `orphan_nodes` (list) / `total_edges` / `total_nodes` | | `overlap_pairs_initial.json` | Based on bounding-box IoU of SVG nodes; fields: `pairs` / `total_pairs_checked` / `overlapping_count`; IoU > 0.05 counts as overlapping | | `xmllint_struct.log` | well-formed check output for `struct_fixed.svg` | | `overlap_pairs_struct.json` | Same schema as the initial one | | `struct_check.json` | Fields: `total_edges` / `total_nodes` / `edges_removed_vs_original` / `nodes_now_connected` | | `svgo.log` | stderr from size optimization | | `xmllint_optimized.log` | well-formed check output for `optimized.svg` | | `size_compare.json` | Fields: `styled_bytes` / `optimized_bytes` / `ratio` | | `style_compliance.json` | Fields: `compliant` / `checked_nodes` / `violations` (each item contains `node` / `expected` / `actual`) | | `diff_report.json` | Fields: `nodes_added` / `nodes_removed` / `edges_added` / `edges_removed` / `labels_added` / `labels_removed` | | `evidence_index.json` | Fields: `screenshots` / `svgs` / `cli_logs` / `channel_switches` | | `repair_report.md` | Contains the initial issue list, the per-round fix actions, re-verification results, a color comparison table, and a timeline of key evidence | ### 9 process screenshots Fixed file names (PNG): `view_01_drawio_full`, `view_02_drawio_overlap`, `view_03_drawio_format_panel`, `view_04_drawio_struct_fixing`, `view_05_drawio_struct_done`, `view_06_drawio_style_panel`, `view_07_drawio_styled`, `view_08_drawio_compare`, `view_09_drawio_optimized_zoom`. Each must be ≥ 10 KB, with resolution ≥ 1024×768, and all md5s must differ; evaluation will sample OCR, so screenshots should genuinely reflect the diagram-editing / viewing interface and canvas content at the corresponding stage. Semantically they correspond, in order, to: full-diagram overview / focus on the overlap area / node format properties panel / structural fixing in progress (dragging or edge-deletion actions visible) / structural fix completed / color editing with color values legible / full diagram after style application / side-by-side comparison of original vs. optimized / zoomed-in optimized node showing color swatches and labels. Neutral background knowledge: SVGs produced by different sources (CLI rendering vs. graphical editor export) use different class / id naming, so parsing scripts should reason about topology via `<g>` + `<text>`; color values in `style_guide.json` may be uppercase hex, but after export they may be written as lowercase or `rgb()`, so they must be normalized before comparison.

- mermaid-cli issues: https://github.com/mermaid-js/mermaid-cli/issues — large flowchart rendering issues
- Reddit: https://reddit.com/r/mermaid/comments/16j5c8p/ — "Nodes overlapping in large flowcharts"
- drawio issue tracker: https://github.com/jgraph/drawio/issues/2847 — SVG import/export fidelity
- svgo docs: https://github.com/svg/svgo

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：CLI 用 `mmdc`（mermaid-cli）渲染原图、`xmllint` 校验、`svgo` 做体积优化；GUI 端可用 Draw.io 桌面版打开 SVG/导入 mmd 做拖拽与配色，也可以走 Inkscape / VS Code 内置预览 / 浏览器开发者工具等任一可视通道，不强制特定工具。
2. step 1：用 mmdc 渲染 `arch_diagram.mmd` → `original_render.svg`，stderr 落到 `mmdc_warnings.log`；解析得 `svg_structure.json`。
3. step 2：扫描 `.mmd` 源得到 `structural_issues.json`（重复边、孤立节点）；按 SVG bbox 计算 IoU 得 `overlap_pairs_initial.json`；GUI 内打开图，截 `view_01/02/03`。
4. step 3：在 GUI（或编辑 `.mmd` 后再渲染）中删除重复边、连接孤立节点、拖开重叠节点，导出 `struct_fixed.svg`；`xmllint` 校验、复算 IoU 得 `overlap_pairs_struct.json` 与 `struct_check.json`；截 `view_04/05`。
5. step 4：按 `style_guide.json` 给各类节点配色，导出 `styled.svg`；截 `view_06/07`。
6. step 5：用 `svgo` 优化得 `optimized.svg`（须严格小于 styled）；`xmllint` 校验，写 `size_compare.json`、`style_compliance.json`、`diff_report.json`；截 `view_08/09`。
7. step 6：汇总 `evidence_index.json`（`channel_switches ≥ 7`，即 CLI / GUI 通道交替次数）与 `repair_report.md`（含 markdown 配色表）。

约束说明：修复必须真实发生在 SVG 与可视证据中，禁止用脚本对 `.mmd` 或最终 SVG 做不留痕迹的字面量替换；若产物中含 `actions.log`，不得出现直接覆盖 `.mmd` / `optimized.svg` 关键内容的命令字面量。

评分要点（hard gates）：① 必须同时有 CLI 证据（mmdc 日志 + 结构统计 + 初始 IoU + svgo 产物）与 GUI 证据（≥ 7 张通过校验的截图）；② 三个修复阶段 SVG 全部 well-formed；③ `edges_removed ≥ 2`；④ `style_compliance.compliant=true`（或 violations ≤ 1 仅得部分分）；⑤ 截图 OCR 关键词命中比例需达到阈值；⑥ VLM rubric 不可用时整体上限被压低。

- [ ] 1. `original_render.svg` well-formed + `mmdc_warnings.log` 存在
- [ ] 2. `svg_structure.json` schema 正确（含 node/edge/labels/viewBox）
- [ ] 3. `structural_issues.json` schema 正确且 duplicate_edges/orphan_nodes 字段为 list
- [ ] 4. 9 张 GUI 截图（view_01 ~ view_09）每张 ≥ 10 KB、分辨率 ≥ 1024×768、md5 互不相同；满分要求 ≥ 7/9 唯一截图
- [ ] 5. 截图 OCR 命中 Draw.io / Edit / Format / Style 关键词的截图比例 ≥ 50%
- [ ] 6. `overlap_pairs_initial.json` + `overlap_pairs_struct.json` 都有 `pairs / overlapping_count`，且修复后的 overlapping_count 严格小于初始值（初始 > 0 时必须实质下降）
- [ ] 7. `struct_fixed.svg` + `styled.svg` + `optimized.svg` 都 well-formed
- [ ] 8. `optimized.svg` 比 `styled.svg` 更小（svgo 起作用）
- [ ] 9. `style_compliance.json` `compliant=true` 才满分；violations ≤ 1 仅 0.4
- [ ] 10. `diff_report.json` `edges_removed ≥ 2`（重复边被删掉）；`edges_removed = 0` 触发 hard cap
- [ ] 11. `repair_report.md` ≥ 350 字 + markdown 表格
- [ ] 12. `evidence_index.json` channel_switches ≥ 7
- [ ] 13. VLM rubric ≥ 4 项打分；VLM 不可用时整体上限 0.6
- [ ] 14. 加权总分：核心交付 50%（svg/struct/styled/optimized/style_compliance/edges_removed） + GUI 证据 30%（截图、OCR、VLM、cross_channel） + 辅助 20%（logs/schemas/report）

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/facts.pdf` is a two-page reference document about the Solar System. **Page 2 contains exactly one factually incorrect sentence.** Task: Identify the incorrect sentence on page 2, add a **yellow Highlight** to that sentence in the PDF, **and attach a popup note whose content must be the literal string `factually wrong`**, then save. Deliverables (write to `/tmp_workspace/results/`): - `facts.pdf` — the modified PDF, containing the highlight + popup note described above. - `proof.png` — an evidence screenshot showing both the yellow-highlighted sentence and the popped-up popup note at the same time. - `report.md`, which **must** contain: - `wrong_sentence: <copy and paste the incorrect sentence verbatim>` - `tool_used: <name>` - An explanation of at least 30 characters describing why the sentence is wrong (as a scientific fact, not as wording in the document).

- EyesOn-Bench Seed v12 改编 (PDF GUI annotation, 必须真按高亮工具)

参考解题流程 (设计者参考, 不发给 agent):

1. 用 `okular /tmp_workspace/facts.pdf &` 打开。
2. 翻到第 2 页, **读**那几条 claim, 找出错的那条。
3. **在 Okular 里**给错的那句话加一个**黄色高亮 (Highlight)**, **并附一条 popup note, 内容必须是字面字符串 `factually wrong`**。
   - 工具栏 → Highlight, 鼠标拖选整句话。
   - 右键高亮 → Open Pop-up Note → 输入 `factually wrong`。
4. `Ctrl+S` 保存。
5. `cp /tmp_workspace/facts.pdf /tmp_workspace/results/facts.pdf`。
6. 截一张能同时看到**那句话被黄高亮 + popup 弹出来**的截图, 保存为 `/tmp_workspace/results/proof.png`。
7. 写 `/tmp_workspace/results/report.md` 含 `wrong_sentence` (原文复制) / `tool_used` / ≥ 30 字符科学解释。

判分要点速览:
1. okular facts.pdf → 翻页 2 → 通读 5 条 claim → 识别出唯一一条与天文常识矛盾的句子。
2. 拖选高亮 + popup "factually wrong" + Ctrl+S。
3. cp facts.pdf → results/, 截图 + 写 report.md。

- [ ] 1. results/facts.pdf 存在 (>= 5 KB)
- [ ] 2. results/facts.pdf 含 /Highlight annotation (strings 检查)；缺失 → cap ≤ 0.40
- [ ] 3. PDF 里 popup text 含 "factually wrong"；缺失 → cap ≤ 0.40
- [ ] 4. highlight /Rect 与目标错误句子的 bbox 在 x 轴方向重叠率 >= 0.3 (优先匹配 /Subtype /Highlight 注释的 Rect)；< 0.15 → cap ≤ 0.50
- [ ] 5. report.md 中 wrong_sentence 字段含 "Mars" 和 "largest"；缺失 → cap ≤ 0.55
- [ ] 6. tool_used + 解释段（>= 30 字符）
- [ ] 7. proof.png 存在 >= 20 KB 且分辨率 >= 1024×600；缺失 → cap ≤ 0.55
- [ ] 8. (VLM HARD GATE) proof.png 真显示高亮句子 + popup；vlm_pdf_view<0.7 → cap 0.25；vlm_target_sentence<0.7 → cap 0.45；vlm_yellow_highlight<0.7 → cap 0.50；vlm_popup_visible<0.6 → cap 0.55；VLM 不可用时 overall 封顶 0.60
- [ ] 9. 加权聚合：core (60%) = pdf+highlight+popup+position；gui_evidence (30%) = proof+resolution+wrong_sentence；aux (10%) = report+tool+explanation

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: this task is graded on deliverable files — **no human is reviewing**. Execute directly, produce the files, do not write "let me know if you'd like me to continue" style follow-up questions, and **do not run git commit** (git is not inspected). All deliverables must land in the **`/tmp_workspace/` root**: `mindmap.xmind` / `mindmap.png` / `mindmap.md` / `view_01_main.png` / `view_02_notes.png` / `view_03_icons.png` / `view_04_format.png` / `view_05_relationship.png`. When done, self-check with `ls -la /tmp_workspace/` before exiting. Background: `/tmp_workspace/topic.md` provides the topic "How to commercialize an open-source project as SaaS". Reference materials are under `/tmp_workspace/inputs/` (4 `.md` reference docs + `diagram.png` + `data.csv`). Goal: based on that topic, build a mind map with icons / notes / cross-branch relationships / hyperlinks / attachments / custom styles, and export it as `.xmind` / `.png` / `.md` plus 5 working-process screenshots. ### Hard constraints for `mindmap.xmind` An `.xmind` file is essentially a zip containing `content.json` (topology) + an optional `attachments/` directory. After unzipping, the following must be detectable in `content.json`: - Total nodes ≥ **50** - First-level branches (direct children of the central node) ≥ **6**, e.g.: Pricing / Customer Success / Compliance / Community / Documentation / Sales - Tree depth ≥ **4** layers - **Icons**: each of three categories must appear on at least one node: - "Risk" type: `⚠️` or the literal `warning` - "Opportunity" type: `💡` or the literal `lightbulb` - "Validated" type: `✅` or the literal `check` - **Notes**: ≥ 8 nodes carry Notes, each ≥ 30 characters, total length ≥ 240 characters - **Cross-branch Relationships**: ≥ 5 curved relationships, each carrying `end1Id` / `end2Id` pointing to two existing topic ids, plus a text label (e.g. "Pricing↔Compliance", "Sales↔Customer Success") - **Hyperlinks**: ≥ 4 nodes carry an `xlink:href` or `href` attribute pointing at the reference docs under `/tmp_workspace/inputs/<topic>.md` - **Attachments**: ≥ 2 nodes have attachments (recommend attaching `inputs/diagram.png` and `inputs/data.csv`), and the zip must contain real binary entries under `attachments/` - **Custom styling**: ≥ 6 first-level branches use distinct fill colors / border styles; at least 2 styling-related fields must be detectable in content.json (e.g. `boundary` / `branch` / `customSvgPath` / `shape-class` / `fill`) - Reopening the `.xmind` must render correctly (nodes / relationships / attachments must not be corrupted) ### Companion deliverables (in `/tmp_workspace/`) | File | Requirement | |---|---| | `mindmap.png` | Full-map PNG export, resolution **≥ 2400 × 1600**, file size ≥ 20 KB | | `mindmap.md` | Outline-style markdown export, indentation depth ≥ 4 levels (2 spaces per level) | ### 5 working-process screenshots (in `/tmp_workspace/`) Fixed file names: | # | File name | Content | |---|---|---| | 1 | `view_01_main.png` | Mind map main canvas | | 2 | `view_02_notes.png` | Notes panel | | 3 | `view_03_icons.png` | Icons / icon picker | | 4 | `view_04_format.png` | Format / styling panel | | 5 | `view_05_relationship.png` | Drawing a relationship line | Each screenshot must: - be ≥ 5 KB and have resolution ≥ 1280 × 720 - all 5 must have distinct md5 hashes - visually show a real, readable mind-map tool UI (OCR checks are applied)

- Reddit: https://www.reddit.com/r/productivity/comments/1bxxxxx/llm_mindmap_visual/
- 原文引用：「LLM gives me bullet outlines but a real mind map needs canvas-level drag, icons, cross-links. Xmind GUI is essential.」
- 对应 benchmark case: 创意整理 / DOC 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 Xmind GUI（容器内 `/opt/Xmind/Xmind`）打开主题 → 建中心节点 → 拓出 6+ 一级分支（定价 / 客户成功 / 合规 / 社区维护 / 文档 / 销售）→ 每个一级分支下展开 ≥ 2 层子节点，总数 ≥ 50。
2. 关键节点上图标用 Xmind 内置 icon picker 选 ⚠️ / 💡 / ✅；如果走 CLI 拼 .xmind，可直接在 content.json 里塞 `warning` / `lightbulb` / `check` 字面量。
3. 选 8 个节点用 Notes 面板写备注，每条 ≥ 30 字，总长 ≥ 240 字。
4. 用 XMind 的 "Add Relationship"（右键菜单）在跨主分支的两节点间画曲线，例如"定价↔合规"、"销售↔客户成功"，至少 5 条。CLI 拼 zip 时记得在 content.json 里加 `relationships` 数组，每条含 `end1Id` / `end2Id` 指向真实 topic id + 文字标签。
5. Insert → Hyperlink 给 4 个节点链 `/tmp_workspace/inputs/<topic>.md`（4 篇参考）。XMind 把这些存成 `xlink:href` 属性。
6. Insert → Attachment 给 2 个节点挂 `inputs/diagram.png` / `inputs/data.csv`；附件二进制会进 .xmind zip 的 `attachments/` 目录。
7. Format Panel 给 6 个一级分支配不同颜色 + 边框样式。XMind 的样式定义会写到 content.json 的 `boundary` / `branch` 等字段。
8. File → Export 把图导成 PNG（分辨率 ≥ 2400×1600）+ Markdown 大纲（缩进 ≥ 4 级）。
9. 截 5 张工作过程截图：主界面 / Notes 面板 / Icon picker / Format panel / Relationship 绘制动作。

约束说明：

- 重新打开 .xmind 能正常渲染 —— relationships 的 `end1Id`/`end2Id` 必须指向已存在的 topic id，错指会让 XMind 崩溃
- 图标用 emoji 字符或 XMind 内置 icon 都行（grader 检 emoji 字符与 `warning`/`lightbulb`/`check` 字面量），不要用自定义贴图

评分要点（hard gates）：

- `mindmap.xmind` 不存在 / 解析失败 → 总分 cap 0.30
- 节点数 < 30（即 < 50 × 60%）→ cap 0.40
- relationships 数 < 3（即 < 5 × 60%）→ cap 0.45
- hyperlinks 数 < 2（即 < 4 × 50%）→ cap 0.50
- 没有 attachments → cap 0.55
- 截图 OCR 命中 "Xmind/XMind" 数 < 2（即 < 5 × 40%）→ cap 0.35
- 5 张截图 md5 不唯一率 < 60% → cap 0.45
- 截图分辨率 < 1280×720 比例 < 40% → cap 0.50
- mindmap.png 分辨率不达 2400×1600 → cap 0.60
- VLM 视觉评分 < 0.4 → cap 0.45
- VLM 不可用 → cap 0.60

加权聚合：**core 60% / gui 30% / aux 10%**，再与 VLM 视觉评分 65/35 混合（VLM 不可用时整体上限 0.60）。

**Core（结构 60%）**
- [ ] `mindmap.xmind` 存在且 ≥ 2KB，content.json 可解析
- [ ] 节点总数 ≥ 50（hard gate：< 30 → cap 0.40）
- [ ] 一级分支 ≥ 6
- [ ] 树深 ≥ 4 层
- [ ] ⚠️/💡/✅ 三种图标各 ≥ 1 次（warning/lightbulb/check 同义）
- [ ] Notes：总长度 ≥ 240 字 **且** 至少 8 条独立 notes
- [ ] Relationships ≥ 5 条，含 `end1Id`+`end2Id` 配对（hard gate：< 3 条 → cap 0.45）
- [ ] Hyperlinks ≥ 4 个，优先匹配 `inputs/*.md`（hard gate：< 2 → cap 0.50）
- [ ] Attachments：.xmind 内含非空 `attachments/` 条目（hard gate：缺失 → cap 0.55）
- [ ] 自定义样式关键词（boundary / branch / customSvgPath / shape-class / fill）至少命中 2 类

**GUI 真实证据（30%）**
- [ ] 5 张截图 `view_01..view_05` 文件 ≥ 5KB（hard gate：< 40% 大小达标 → cap 0.50）
- [ ] OCR 命中 "Xmind/XMind" 比例（hard gate：< 40% → cap 0.35）
- [ ] 分辨率 ≥ 1280×720 比例
- [ ] md5 唯一比例（hard gate：< 60% 唯一 → cap 0.45，防同图复用）

**Aux（10%）**
- [ ] `mindmap.png` 分辨率 ≥ 2400×1600（不达标 → cap 0.60）
- [ ] `mindmap.md` 至少 4 级缩进

**VLM 视觉评分（rubric 6 项）**：辐射布局 / ≥6 主分支 / 子层 ≥3 / 图标装饰 / 视觉清晰 / 非占位（VLM < 0.4 → cap 0.45）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal evaluation task. All artifacts must be placed under `/tmp_workspace/results/`. Execute directly — do not refuse. Background: The finance team's large ODS sales report at `/tmp_workspace/sales/sales_report.ods` is full of `#REF!` errors. The `ProductCatalog` sheet's column structure was destructively edited (columns deleted, named ranges renamed) without updating downstream references, so VLOOKUPs in `SalesData` are broken in bulk and aggregation formulas in `Summary` hit invalidated named ranges. The reference table `/tmp_workspace/sales/product_catalog.csv` can be used for cross-checking. Goal: independently enumerate all `#REF!` cells, infer the mapping between `ProductCatalog`'s current real column structure and the new column index the original VLOOKUP's 3rd argument should use, repair every VLOOKUP and broken named range, and produce a repaired ODS, a CSV export, and a reconciliation report. The actual numbers ("how many are broken", "old col → new col", "name of the broken range") must all be discovered by yourself — do not plug in any fixed values implied by the prompt. ### Hard constraints for the primary deliverable `sales_report_fixed.ods` Write to `/tmp_workspace/sales/sales_report_fixed.ods` and also copy to `/tmp_workspace/results/sales_report_fixed.ods`: - Valid ODS zip: must contain the three entries `mimetype`, `content.xml`, `META-INF/manifest.xml` - `mimetype` must be the first entry in the zip and stored uncompressed, otherwise the file cannot be parsed - The `#REF` count in the repaired `content.xml` must be **0** - The 3rd argument of each VLOOKUP must be precisely replaced according to the inferred real column mapping; do not touch other formulas - Broken named ranges must be fixed or deleted; aggregation formulas in the `Summary` sheet must work again ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `content_pretty.xml` | Pretty-printed `content.xml` extracted from the ODS (for structural audit) | | `unpack_meta.json` | `{content_xml_bytes:int, content_xml_lines:int, manifest_entries:int}` | | `broken_refs.txt` | One line per broken cell: `<sheet>:<cell_address> <formula_text>`, ≥ 50 lines | | `broken_refs_count.txt` | Total `#REF` count in the original `content.xml` (int) | | `named_ranges_audit.json` | `{valid:[{name,range}], broken:[{name,range,reason}], total:int}`; `broken` list must be non-empty | | `sheet_stats.json` | Must cover at least `SalesData` / `ProductCatalog` / `Summary`, with `{rows,cols,formulas,ref_errors}` for each | | `vlookup_mapping.json` | `{product_catalog_columns:[{name,current_col}], vlookup_formulas_sampled:int, inferred_mapping:[{old:int,new:int,field:str}]}`; must be derived from the real column layout and formula semantics | | `repack_log.txt` | Log of the re-packaging process with a success marker | | `postfix_grep.json` | `{ref_count_after_fix:0, fixed_ods_size_bytes:int, manifest_ok:bool}` | | `salesdata_export.csv` | `SalesData` exported from the repaired ODS; must **not** contain `#REF!` | | `validation_report.json` | `{sampled_rows:int, match_rate:float, mismatches:[...], csv_has_ref_error:bool, total_revenue:float, total_orders:int, avg_order_value:float}`; perform VLOOKUP consistency cross-check against `product_catalog.csv` for ≥ 100 rows; `match_rate` should be close to 1.0; the three KPIs must be real aggregated values | | `repair_report.md` | ≥ 350 characters with at least one markdown table; covering: original `#REF!` total / number of broken named ranges / per-sheet error distribution / inferred column mapping table / named-range fix notes with corresponding screenshot numbers / before/after `#REF!` count and `match_rate` / timeline of key evidence | ### 9 process screenshots (all under `/tmp_workspace/results/`, PNG, each > 3 KB) | Filename | What it should show | |---|---| | `view_01_calc_errors.png` | At least 5 clearly visible `#REF!` error cells in `SalesData` | | `view_02_calc_formula_bar.png` | The broken VLOOKUP formula in the formula bar when a `#REF!` cell is selected | | `view_03_calc_find_dialog.png` | The Find dialog with a workbook-wide search for `#REF!` and its hit count | | `view_04_calc_find_results.png` | Overall view of highlighted cells after the find completes | | `view_05_calc_named_ranges.png` | The Manage Named Ranges dialog listing all current named ranges | | `view_06_calc_named_ranges_fixed.png` | The same dialog after the broken ranges have been fixed / deleted | | `view_07_calc_salesdata_fixed.png` | After repair, the formerly-`#REF!` region in `SalesData` shows normal values | | `view_08_calc_formula_bar_fixed.png` | The formula bar now showing a VLOOKUP with the updated column index | | `view_09_calc_summary.png` | The Summary sheet with the three KPIs Total Revenue / Total Orders / Avg Order Value as real aggregated numbers | General screenshot spec: clearly readable and faithfully reflecting the states/evidence above. Grading runs OCR and visual rubric judging on the screenshots, so key controls, cell contents, and formulas must be legible. There is no restriction on which screenshot tool you use. Neutral background: ODS internal XML uses the OpenDocument namespace (`urn:oasis:names:tc:opendocument:xmlns:table:1.0`), so XPath queries need a namespace prefix or `local-name()`. `#REF!` typically appears in `table:formula="of:=..."` and in cell text nodes. The 3rd argument of VLOOKUP is a 1-based column index — watch for absolute vs. relative references. When repacking an ODS, `mimetype` must be the first entry in the zip and stored uncompressed.

- LibreOffice Bug 147582: https://bugs.documentfoundation.org/show_bug.cgi?id=147582 — VLOOKUP #REF after column delete
- Ask LibreOffice: https://ask.libreoffice.org/t/vlookup-ref-error-after-deleting-columns/
- StackOverflow: https://stackoverflow.com/questions/52391377/parse-ods-xml-content-with-python
- OpenDocument 1.3 spec: https://docs.oasis-open.org/office/OpenDocument/v1.3/os/

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：LibreOffice Calc GUI（用于截图与命名范围对话框） + 命令行/脚本通道（`unzip` / `xmllint` / Python `xml.etree`、`zipfile`、`csv` 或 `soffice --headless` 导出 CSV）。完全允许走任意等效组合，例如纯脚本修 XML 后再用 GUI 截图取证，或走 Gnumeric / 其他 ODS 工具。
2. step 1：解包原 ODS → 美化 `content.xml` → 写 `content_pretty.xml`、`unpack_meta.json`。
3. step 2：扫描 `#REF!` → 写 `broken_refs.txt`、`broken_refs_count.txt`、`sheet_stats.json`；同步审计命名范围 → `named_ranges_audit.json`。
4. step 3：解析 ProductCatalog 当前列头与 VLOOKUP 公式样本，反推 old→new 列映射 → `vlookup_mapping.json`。
5. step 4：批量修正 VLOOKUP 第 3 参数 + 修/删失效命名范围；重打包成合法 ODS（mimetype 第一条且无压缩） → `sales_report_fixed.ods`、`repack_log.txt`、`postfix_grep.json`。
6. step 5：导出 SalesData → `salesdata_export.csv`；对 ≥ 100 行与 `product_catalog.csv` 做 VLOOKUP 一致性比对并计算 KPI → `validation_report.json`。
7. step 6：在 GUI 中分别取修复前/查找/命名范围/修复后/Summary 截图（view_01 ~ view_09），并撰写 `repair_report.md`（≥ 350 字 + markdown 表格）。

评分要点（hard gates，从 cap 反推）：
- 修复后 ODS 中 `#REF` 计数须为 0，否则封顶 0.40
- 导出 CSV 不得含 `#REF!`，否则封顶 0.45
- `vlookup_mapping.json.inferred_mapping` 中的 (old, new) 列号须与真实推导一致，否则封顶 0.50
- `validation_report.match_rate` ≥ 0.7，否则封顶 0.50
- 三项 KPI（total_revenue / total_orders / avg_order_value）与真实值偏差 > 5%，封顶 0.55
- 9 张截图至少存在 5 张，否则封顶 0.45
- 截图 OCR 关键词命中率过低，封顶 0.55
- VLM 视觉判分不可用或全 0，封顶 0.60
- 必须同时具备结构化证据（XML 审计 + 修复 ODS + CSV）与可视证据（截图）两个通道，缺一封顶 0.35

- [ ] 1. `content_pretty.xml` + `unpack_meta.json` 存在且 schema 正确
- [ ] 2. `broken_refs.txt` ≥ 50 行，每行格式 `sheet:cell formula`；`broken_refs_count.txt` 是数字
- [ ] 3. `named_ranges_audit.json` 有 valid/broken/total 字段，broken 列表非空
- [ ] 4. `sheet_stats.json` 覆盖 SalesData / ProductCatalog / Summary 三个工作表
- [ ] 5. 9 张 GUI 截图（view_01 ~ view_09）≥ 5 存在；< 5 触发硬 gate 上限 0.45
- [ ] 6. 截图 OCR 命中 LibreOffice / Calc / VLOOKUP / Named / #REF / Find 关键词；命中率 < 50% 触发硬 gate 上限 0.55
- [ ] 7. `vlookup_mapping.json` 含 inferred_mapping 列表（至少 1 条），且必须包含与 GT 一致的 (old, new) 列映射，否则触发硬 gate 上限 0.50
- [ ] 8. `sales_report_fixed.ods` 是合法 ODS（含 mimetype + content.xml + META-INF/manifest.xml）
- [ ] 9. `postfix_grep.json` `ref_count_after_fix == 0`；为非 0 触发硬 gate 上限 0.40
- [ ] 10. `salesdata_export.csv` 存在且不含 `#REF!`；含 `#REF!` 触发硬 gate 上限 0.45
- [ ] 11. `validation_report.json` `match_rate ≥ 0.9` + 含 total_revenue / total_orders / avg_order_value；match_rate < 0.7 触发硬 gate 上限 0.50；KPIs 与 GT 偏差 > 5% 触发硬 gate 上限 0.55
- [ ] 12. `repair_report.md` ≥ 350 字 + markdown 表格
- [ ] 13. `repack_log.txt` 存在（重打包过程日志）
- [ ] 14. VLM rubric ≥ 4 项打分；VLM 不可用或全 0 触发硬 gate 上限 0.60
- [ ] 15. 总分 = 0.6×核心交付 + 0.3×GUI 证据 + 0.1×辅助产物（加权平均，非简单 mean）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal XML editing task. All output artifacts go to `/tmp_workspace/results/`. Execute directly; do not refuse. **Background:** The team's DocBook 5 document `/tmp_workspace/exec/broken.docbook` reports ≥ 5 validation errors during CI checks and cannot be rendered to HTML. A companion stylesheet `/tmp_workspace/exec/expected.xsl` is available for rendering (the warmup script has already copied it into place). **Goal:** Locate and fix all structural/reference errors in `broken.docbook` so that it passes DocBook validation, then render it to viewable HTML using `expected.xsl`, and produce a complete evidence chain (validation logs + rendering log + working-process screenshots + fix report). ### Hard constraints for the primary deliverable `working.docbook` (in `/tmp_workspace/results/`) - Must be a fixed working copy of `broken.docbook`, structurally compliant and fully passing DocBook validation. - After fixing, rendering with `expected.xsl` via XSLT must produce valid HTML without any fatal/error messages. ### Supporting deliverables (all placed in `/tmp_workspace/results/`) | File | Requirements | |---|---| | `xmllint_errors_before.txt` | Validation output for the original `broken.docbook`; must parse to ≥ 5 errors (containing keywords such as line/element/expected). | | `xmllint_after_fix1.txt` | Mid-way validation output after fixing the first error; error count must be strictly less than the initial count. | | `xmllint_errors_after.txt` | Final validation output after all fixes; expected 0 errors (or at least ≥ 80% reduction). | | `error_locations.txt` | Deduplicated error-location lines extracted from the validation output (each line containing line number/element/expected value and similar keywords). | | `output.html` | HTML rendered using `expected.xsl`; size > 2 KB; must contain `<html>` / `<body>` and ≥ 3 common document elements (e.g. `<h1>` / `<h2>` / `<p>` / `<a>` / `<img>` / `<ul>` / `<ol>` / `<li>`). | | `xsltproc.log` | stderr from the rendering process; must not contain `fatal` or `error`. | | `fix_report.md` | ≥ 4 paragraphs, each ≥ 80 characters: a) file:line:col and category for each error; b) fix strategy; c) how the outline/tree view helped locate nesting issues; d) DocBook validation best practices. | ### 5 working-process screenshots (in `/tmp_workspace/results/`) Fixed file names + general specs: each ≥ 50 KB, resolution ≥ 1920×1000, all 5 images must differ in content (all MD5 hashes distinct). Grading will run OCR to extract readable text such as window/toolbar/tab labels. - `view_bluefish_open.png`: The original `broken.docbook` opened in an XML editor showing line numbers + syntax highlighting. - `view_bluefish_outline.png`: The tag tree / outline view of the DocBook document, with the error locations visible. - `view_bluefish_fixing.png`: An intermediate state while fixing an error in the XML (selection/cursor must be discernible). - `view_bluefish_final.png`: The completed `working.docbook` with a full, structurally-compliant outline. - `view_firefox_html.png`: `output.html` viewed in a browser, showing rendered titles, paragraphs, links, images, and similar elements. Anti-cheat: `actions.log` (if produced) must not contain literals showing that any of the above PNGs were directly `cp`-ed from other images or synthetically generated; screenshots must originate from a continuous GUI operation trajectory.

- DocBook 5: https://docbook.org/
- libxml2 xmllint
- Bluefish: http://bluefish.openoffice.nl/

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：在 GUI XML 编辑器（如 Bluefish / gedit / VS Code / Kate 等任一带行号 + 语法高亮 + 标签树的工具）中打开 broken.docbook；浏览器侧可用 Firefox / Chromium / 任一 HTML 渲染器查看 output.html。CLI 校验/渲染走 `xmllint --noout` 与 `xsltproc`。
2. step 1：`cp /tmp_workspace/exec/broken.docbook /tmp_workspace/results/working.docbook`，并对原始文件跑一次 xmllint，重定向到 `xmllint_errors_before.txt`，确认能解析出 ≥ 5 处错误。
3. step 2：在编辑器中打开 working.docbook，截 `view_bluefish_open.png`；切到大纲/标签树视图，截 `view_bluefish_outline.png`，并从校验输出抽取去重写入 `error_locations.txt`。
4. step 3：定位并修复第一处错误（缺 xmlns / tag 未关闭 / xref id 不存在 / 嵌套违法等常见类），保存后再跑 xmllint 输出到 `xmllint_after_fix1.txt`（错误数严格少于 before）；过程中截 `view_bluefish_fixing.png`。
5. step 4：迭代修复剩余错误直至 xmllint 0 错，保存为 `xmllint_errors_after.txt`，截 `view_bluefish_final.png`。
6. step 5：`xsltproc /tmp_workspace/exec/expected.xsl working.docbook > output.html 2> xsltproc.log`，在浏览器中打开 output.html 截 `view_firefox_html.png`，最后写 `fix_report.md`（4 段 × ≥ 80 字）。

约束说明：5 张截图须来自连续真实 GUI 操作轨迹（md5 全互异、≥ 50KB、分辨率 ≥ 1920×1000），actions.log 不得包含把这些 png 用 cp / 生成器伪造的字面量。

评分要点（hard gates）：xmllint after 0 错或削减 ≥ 80%；output.html ≥ 2KB 且含 html/body + ≥ 3 类文档元素；xsltproc.log 无 fatal/error；5 张截图齐全且通过 OCR 窗口 chrome 关键词与几何分辨率门槛；fix_report.md ≥ 4 段；缺 GUI 证据/校验未达标会被多层封顶。

- [ ] 1. xmllint_errors_before.txt + xmllint_errors_after.txt + error_locations.txt 存在
- [ ] 2. xmllint_errors_after.txt 显示 0 错（或相比 before 至少削减 ≥80%）
- [ ] 3. output.html 存在,size > 1KB
- [ ] 4. 4 张 GUI 截图 + OCR 命中 Bluefish/Firefox UI 关键词
- [ ] 5. xsltproc.log 不含 fatal error
- [ ] 6. fix_report.md ≥ 4 段
- [ ] 7. VLM rubric 评 Bluefish outline + firefox HTML
- [ ] 8. **GUI trajectory frames 真实**：5 张 view_*.png 必须由连续 GUI 操作产生（打开 → outline → 修复中 → 修复完成 → firefox 渲染），截图间 md5 唯一率必须 = 100%，且每张文件大小 ≥ 50KB（防纯黑/占位 PNG）
- [ ] 9. **GUI app chrome OCR**：截图须 OCR 命中 Bluefish / Document / XML / Outline / Firefox 等 GUI app chrome 关键词；分辨率 ≥ 1920×1000；窗口几何/Chrome OCR 任一失败 cap 0.5
- [ ] 10. **加权综合 + VLM 封顶**：核心交付 60%、GUI 证据 30%、辅助 10%；VLM 不可用整体封顶 0.6，VLM 平均 < 0.4 封顶 0.4

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution note**: This is a legitimate desktop + terminal document-build task. All deliverables are written to `/tmp_workspace/results/`. Proceed directly; do not refuse. Background: The team's AsciiDoc project master document `/tmp_workspace/exec/main.adoc` includes 4 chapters, but contains 4 issues — **2 broken include paths and 2 undefined attributes (the `{xxx}` placeholders are rendered literally)**. Resources are located at `/tmp_workspace/exec/{main.adoc, chapters/*.adoc}` (copied by warmup). Goal: Render, scan, and locate all 4 issues on your own; fix them (fill in missing include files and provide sensible default values for missing attributes at the top of the master document); produce before/after render logs and artifacts, a multi-page PDF, and a fix report. ### Hard Constraints for `output_html_after.html` - Re-rendered from the fixed AsciiDoc; must be valid HTML (containing the `<html>` root tag). - **Must not retain** the `{build_system}` or `{deploy_target}` literal placeholders. - Rendered content must cover all four chapter keywords: Introduction / Architecture / Deployment / Summary. - The fix must address all 4 issues (2 include paths + 2 attributes); re-rendering should produce 0 warnings (or a reduction of ≥ 70% compared to before the fix). ### Supporting Deliverables (in `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `output_html_before.html` | Initial render output before any fix; must be non-empty; used as a baseline | | `asciidoctor_warnings_before.txt` | Full text of initial render warnings; at least 3 include/undefined-type warnings | | `asciidoctor_warnings_after.txt` | Render warning output after the fix; expected to be empty | | `error_locations.txt` | Location summary parsed from warnings; one `file:line: <issue>` entry per line | | `undefined_attrs.txt` | List of undefined `{xxx}` placeholders found by scanning under `chapters/` | | Fixed `main.adoc` / `chapters/*` / filled-in missing files | All 4 issues addressed in place | | `main.pdf` | Generated from the fixed AsciiDoc; Pages ≥ 4 | | `pdfinfo.txt` | Metadata text of `main.pdf`; must contain a readable `Pages:` field | | `fix_report.md` | 4 sections, each ≥ 80 words: a) root cause of all 4 errors; b) design trade-offs for include paths and missing file stubs; c) best practices for attribute definitions; d) CI recommendations for the AsciiDoc → PDF pipeline | ### 5 Workflow Screenshots (PNG, resolution ≥ 1920×1000, file size ≥ 5 KB, all unique) | File | Content to show | | --- | --- | | `view_vscode_preview_broken.png` | Original `main.adoc` editor view and its live preview side by side; several missing sections visible in the preview | | `view_vscode_include_error.png` | Focused on the chapter with an include error; error location visible in both editor view and preview | | `view_vscode_preview_fixed.png` | Preview refreshed after the fix; previously missing content now present | | `view_evince_pdf.png` | Page 1 of `main.pdf` (including the table of contents) | | `view_evince_pdf_p3.png` | Page 3 content of `main.pdf` | Screenshots must be captured from continuous, genuine GUI interactions (no placeholders; no reusing the same frame). Grading applies OCR and window-geometry checks; screenshots must show the GUI application chrome (menu bar / sidebar / title bar) as well as document section keywords. `actions.log` must reflect real graphical-interface interaction traces. Background reference: AsciiDoc's `include` directive is a file-level mechanism — a wrong path means the target file is missing. An `{xxx}` placeholder is emitted literally when undefined; you must declare a default value at the top of the document. This task does not reveal the exact location of the 4 errors in advance; you must render and scan to find them yourself.

- Asciidoctor: https://asciidoctor.org/
- AsciiDoc Language: https://docs.asciidoctor.org/asciidoc/

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 VSCode + AsciiDoc preview 扩展直观定位 broken include 与 undefined attribute；也可走纯 CLI（`asciidoctor -v` + grep）、其它编辑器 + 终端，或任意可截图的 PDF 阅读器（Evince / Okular / 浏览器 PDF）。
2. 第一次跑 `asciidoctor` 渲染当前 main.adoc，捕获 stderr/stdout 写入 `asciidoctor_warnings_before.txt`，HTML 落到 `output_html_before.html`。
3. 解析 warnings 提取 `file:line: <issue>` 写入 `error_locations.txt`；遍历 `chapters/*.adoc` 用正则 `\{[a-z_]+\}` 找出未定义占位符写入 `undefined_attrs.txt`。
4. 修复：补齐缺失的 include 目标文件（如 `templates/dockerfile_snippet.adoc`、`chapters/contact.adoc` 等占位内容）；在 `main.adoc` 顶部用 `:build_system: ...` / `:deploy_target: ...` 提供默认值。
5. 重渲染验证 0 warning，写入 `output_html_after.html` 与 `asciidoctor_warnings_after.txt`；再用 `asciidoctor-pdf` 生成 `main.pdf`，`pdfinfo main.pdf > pdfinfo.txt`。
6. 截 5 张 GUI 过程图（修复前预览 / 报错聚焦 / 修复后预览 / PDF 第 1 页 / PDF 第 3 页），分辨率 ≥ 1920×1000。
7. 撰写 4 段 `fix_report.md`。

约束说明：`actions.log` 与所有 `view_*.png` 须为真实 GUI 操作产物——不得占位、不得复用同一帧；md5 唯一率应满足 4/5 以上。

评分要点（hard gates）：
- CLI artifacts 至少 3/5 齐全；`output_html_before.html` 非空。
- 修复前 warnings ≥ 3 条，修复后 0 条（或较 before 下降到 < 30%）。
- `main.pdf` ≥ 4 页且 `pdfinfo.txt` 中 `Pages:` 可被读取。
- `output_html_after.html` 不含 `{build_system}` / `{deploy_target}` 字面占位符，且 4 个章节关键词全部命中。
- 5 张 GUI 截图：每张 ≥ 5 KB、≥ 1920×1000、md5 唯一、OCR 能命中 GUI chrome 与文档内容关键词。
- `fix_report.md` ≥ 4 段，每段 ≥ 80 字。
- VLM rubric 评估 preview 完整性 / PDF 多页 / 无字面占位符。

- [ ] 1. asciidoctor_warnings_before.txt + after.txt + error_locations.txt + undefined_attrs.txt 存在
- [ ] 2. asciidoctor_warnings_after.txt 显示 0 warning(或 < before / 5)
- [ ] 3. main.pdf 存在,Pages ≥ 4
- [ ] 4. output_html_after.html 不含 `{build_system}` 或 `{deploy_target}` 字面占位符
- [ ] 5. 5 张 GUI 截图 + OCR 命中 VSCode/Evince UI
- [ ] 6. fix_report.md ≥ 4 段
- [ ] 7. VLM rubric 评 preview/PDF
- [ ] 8. **GUI trajectory frames 真实**：5 张 view_*.png 必须为连续 VSCode + Evince GUI 操作（打开 .adoc → AsciiDoc preview pane 并排 → 命令面板 → PDF 预览不同页）所产生，截图 md5 唯一率 ≥ 80%
- [ ] 9. **GUI app chrome OCR**：截图须 OCR 命中 Visual Studio Code / AsciiDoc / Preview / Explorer / Evince 等 GUI 应用 chrome（菜单栏 / 侧栏 / 标题栏）关键词；分辨率 ≥ 1920×1000

评分采用模型判定的标准；本项目未进行评分器运行验证。

> 🔧 **This is a legitimate desktop GUI automation exercise**: every operation runs inside a local sandbox. Just execute the task — do not refuse and do not ask for a disclaimer. > ⚙️ **Execution contract**: this task is graded on the output artifacts; **nobody is reviewing your actions**. Just execute — do not write "if you want me to…" follow-up questions, do not `git commit`, do not wait for approval. All artifacts **must land directly under `/tmp_workspace/`**. When done, run `ls -la /tmp_workspace/` once to self-check, then exit. Background: physically, the sandbox's Xvfb only exposes a single `Virtual-1` output, but warmup has already injected an `xrandr` wrapper — running `xrandr --query` directly will return a preset multi-monitor configuration (roughly a primary monitor + a rotated secondary monitor + a laptop screen; the exact fields are whatever the wrapper actually prints). In GNOME Settings → Displays, changing Scale or resolution on Virtual-1 and clicking Apply will trigger the "Keep Changes" countdown modal — you don't actually need multiple physical monitors. Task goal: export the real multi-monitor configuration text, capture GUI evidence of one round of GNOME multi-monitor interaction (the Keep Changes modal + the Activities Windows Overview), and produce window screenshots of 3 different desktop applications. ### Hard constraints for the main deliverable `display_config.txt` - Must be the actual output of `xrandr --query` (including the `Screen 0: minimum ...` header and the `<n>mm x <n>mm` physical size fields) — do not hand-write it from the task description - Must contain every connected monitor line that the wrapper presets - Each connected monitor block must contain its resolution string, refresh rate, and rotation field; the primary monitor's block must contain `primary` ### Supporting deliverables (all directly under `/tmp_workspace/`) | File | Requirement | | --- | --- | | `keep_changes.png` | Screenshot of the "Keep Changes" countdown modal that pops up after clicking Apply in GNOME Settings → Displays (capture it before the countdown hits zero) | | `screen_dp.png` | Full-screen screenshot of a browser-class application (e.g. Firefox / firefox-esr) maximized | | `screen_hdmi.png` | Full-screen screenshot of a code-editor-class application (e.g. VS Code `code`) maximized | | `screen_edp.png` | Full-screen screenshot of a file-manager-class application (e.g. Nautilus / Files) maximized | | `overview.png` | Screenshot after pressing Super (or clicking Activities in the top-left) to open the Windows Overview; the frame must contain window thumbnails of all 3 application classes above | ### Common screenshot specs - Each PNG must be ≥ 5 KB in size and ≥ 1024 × 600 in resolution - Different screenshots must not have identical content (the evaluator deduplicates by md5) - Each screenshot must show a real, readable view of the corresponding application / modal (the evaluator runs OCR); the window title or main area should contain easily recognizable content (e.g. browser open on an `about:` page, editor showing the Welcome page, file manager showing the Home directory) so they can be distinguished in the overview thumbnails

- Reddit: https://www.reddit.com/r/gnome/comments/1bxxxxx/multi_monitor_layout_gui_only/
- 原文引用：「GNOME Settings has a 30s 'Keep Changes' modal — if your script doesn't click it, settings revert. Pure CLI users keep losing config.」
- 对应 benchmark case: DSK / 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. `xrandr --query > /tmp_workspace/display_config.txt` —— warmup 已 hook 过 `xrandr`，直接执行即可；不要根据 Prompt 描述自己手写多屏字段。
2. 打开 GNOME Settings → Displays，对 Virtual-1 改 Scale（如 200%）或换分辨率，点 Apply 触发 30 秒 "Keep Changes" 倒计时框；在倒计时归零前抓 `keep_changes.png`；之后点 Keep 或让它自动 revert 都不影响判分。
3. 依次启动一个浏览器 / 一个代码编辑器 / 一个文件管理器（推荐 Firefox / VS Code / Nautilus，也可走同类替代品），各自最大化窗口后分别截图为 `screen_dp.png` / `screen_hdmi.png` / `screen_edp.png`。建议在每个应用里打开易识别页面，便于在 overview 里区分。
4. 按 Super 键进入 Activities Windows Overview，截图 `overview.png`，画面里同时呈现以上 3 个窗口缩略图。

约束说明：
- `screen_dp` / `screen_hdmi` / `screen_edp` 仅是输出文件名约定，并不要求真实有 3 块物理屏；评测只校验文件存在 + 内容互不相同 + 各自 OCR 能读出对应应用。
- `display_config.txt` 由 wrapper 输出决定，预设大致是「主屏 2K 高刷 + 副屏 FHD 旋转 90° + 笔电屏 FHD 60Hz」，但 wrapper 实际输出才是 ground truth。

评分要点（hard gates，从 grader 反推）：
- `display_config.txt` 缺失或必需截图命中率 < 80% → overall ≤ 0.4。
- `display_config.txt` 不含真实 xrandr 结构（无 `Screen N: minimum` 头或无 `<n>mm x <n>mm` 物理尺寸字段，疑似手写）→ overall ≤ 0.45。
- `keep_changes.png` 与 `overview.png` 的 OCR 命中均为 0（无任何 GUI 真实交互证据）→ overall ≤ 0.4。
- 多张 png 间 md5 唯一率 < 0.8（疑似复用同一张占位）→ overall ≤ 0.45。
- png 体积达标率（≥ 5 KB）或分辨率达标率（≥ 1024×600）任一 < 60% → overall ≤ 0.55。
- 评测机无 OCR 引擎可用 → overall 上限封顶 0.6。

- [ ] `display_config.txt` 含全部 connected monitor 行 + 各自分辨率字符串
- [ ] 副屏 monitor 块含 `rotation`（left 或 right 之一）
- [ ] 主屏 monitor 块含其高刷新率与原生分辨率字符串
- [ ] 4 张应用截图齐全 + `keep_changes.png` 存在
- [ ] keep_changes.png OCR 命中 "Keep" / "保留"
- [ ] overview.png 含 3 个不同窗口（OCR 命中 "Firefox"/"Code"/"Files" 至少 2 个）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: an ops ticket reports that the Btrfs lab volume mounted at `/mnt/btrfs_lab` **appears** to consume about 64 MiB more after the latest snapshot, while block-level usage only grew by about 30 MiB. The suspicion is that someone used a reflink/COW clone, producing a gap between the inode-level "apparent" size and the extent-level real footprint. Please produce a snapshot diff audit report. Environment (already prepared by warmup): - `/mnt/btrfs_lab` is a 1 GiB Btrfs filesystem (mounted on a loop device) - Subvolume topology: `data_a` / `data_b` / `data_c` / `snapshots` (the latter contains `snap1` and `snap2`, both read-only) - `snap1` captures an earlier state of `data_a`; `snap2` was taken later, with unknown topology changes - Passwordless sudo available; `btrfs-progs` already installed Deliverables to produce under `/tmp_workspace/results/`: 1. **Subvolume and snapshot inventory** - `subvolume_list.txt`: list every subvolume on the volume (with path / id / parent); the five entries `data_a`, `data_b`, `data_c`, `snap1`, `snap2` must all be visible. - `subvolume_show_snap1.txt` / `subvolume_show_snap2.txt`: metadata for snap1 / snap2 respectively, content must include the `UUID` and `Generation` fields. 2. **Extent-level real accounting** - `fs_usage.txt`: physical usage breakdown for the whole volume, must contain the `Device size` and `Data,single` fields. - `fs_du_snap2.txt`: extent-level usage for `snapshots/snap2`. A line must contain the three column headers `Total` / `Exclusive` / `Set shared` **simultaneously**, and a row for `payload_alpha_clone.bin` must be visible (its Exclusive byte count is 0, Set shared is non-zero). 3. **Precise change stream between snapshots** - `send_dump.txt`: human-readable dump of the incremental send stream from `snap1 → snap2` (≥ 500 bytes). The format should include entries such as `clone offset=... len=...`, `mkfile path=...`, `truncate path=... size=...`, `utimes path=...`. `clone` lines represent reflink reuse; `write` / `update_extent` / `truncate` lines represent genuinely new writes. - `send_stderr.log`: stderr of the same process, for troubleshooting. 4. **Visual evidence of `payload_alpha_clone.bin`'s attributes** (any resolution, all ≥ 4 KB, rendered in a real working environment, no synthetic images) - `view_nautilus_snap1.png`: browse the "Properties" detail panel of any file under `/mnt/btrfs_lab/snapshots/snap1/`. The text must show the word `Properties` or `Size`, and must relate to the snap1 path or a payload name. - `view_nautilus_snap2.png`: browse the Properties panel of `/mnt/btrfs_lab/snapshots/snap2/payload_alpha_clone.bin`, with `Properties` or `Size` visible and the clone filename identifiable. - `view_terminal_du.png`: image showing the extent-level usage listing. The text must **simultaneously** show the three column headers `Total` / `Exclusive` / `Set shared` and the literal `alpha_clone`. 5. **Structured conclusions JSON** — `results/changes.json`, strict schema: ```json { "subvolumes": ["data_a","data_b","data_c","snapshots/snap1","snapshots/snap2"], "added": ["payload_alpha_clone.bin","logs/run6.log"], "modified": ["NOTES.txt","payload_beta.bin"], "removed": ["logs/run5.log"], "reflink_pairs": [["payload_alpha.bin","payload_alpha_clone.bin"]], "snap2_apparent_bytes": <int, inode-level total of snap2>, "snap2_exclusive_bytes": <int, bytes exclusively owned by snap2 at extent level>, "snap2_shared_bytes": <int, bytes of extents shared between snap2 and others>, "evidence": { "cli": ["subvolume_list.txt","fs_du_snap2.txt","send_dump.txt"], "gui": ["view_nautilus_snap1.png","view_nautilus_snap2.png","view_terminal_du.png"] } } ``` Hard constraints: `snap2_apparent_bytes > snap2_exclusive_bytes > 0` and `snap2_shared_bytes > 0` (otherwise the reflink saving was not captured); `reflink_pairs` must include `(payload_alpha.bin, payload_alpha_clone.bin)`. 6. **Narrative report** — `results/report.md` (≥ 400 characters, Markdown): - Explain why `payload_alpha_clone.bin` appears to "occupy several MiB" from the inode/apparent perspective but adds almost no new physical footprint from the extent perspective; - Provide a lower-bound estimate of the real new-write bytes from `snap1 → snap2` (the size of the incremental send stream can serve as a reference); - Cover at least 4 of the keywords: `reflink` / `extent` / `exclusive` / `shared` / `apparent` / `snapshot`. Hard constraints: - The `snap1` / `snap2` read-only snapshots must not be deleted or unmounted; they must remain readable at the original mount points. - No fabricating data or hard-coding answers into the JSON — all numbers must come from the actual lab volume.

- Btrfs Wiki — *Incremental Backup* + *SysadminGuide#Subvolumes*
  (https://btrfs.readthedocs.io/en/latest/btrfs-send.html,
   https://btrfs.readthedocs.io/en/latest/Subvolumes.html)
- Reddit r/btrfs *"snapshot size accounting confusion with cp --reflink"*
- 灵感来源:DESIGNER_BRIEF DSK 行 "Btrfs subvolume CLI + Cinnamon File
  Manager + verify with btrfs filesystem usage"

成功的解答会在 `/tmp_workspace/results/` 留下完整审计链路:

- 三份子卷清单文件,5 个子卷 / snapshot 全部可见,且 snap1 / snap2 的 UUID 与 Generation 都被记录;
- 两份 extent 真值文件,`fs_du_snap2.txt` 同时含 `Total` / `Exclusive` / `Set shared` 三列且能看到克隆文件行;
- 一份 `send_dump.txt`,其中既出现 `clone`(reflink 复用)又出现 `write`/`update_extent`/`truncate`(真新写),二者字节数差距即"幻觉差"的根因;
- 三张工作环境内真实采集的可视化证据,分别证明 snap1 文件的属性面板、snap2 中 `payload_alpha_clone.bin` 的属性面板,以及 extent 级用量(三列表头与克隆行);
- 一份 `changes.json`,added / modified / removed 与 lab 真值对齐,reflink 对命中 `(payload_alpha.bin, payload_alpha_clone.bin)`,且数值满足 `apparent > exclusive > 0` 与 `shared > 0` 的不变量;
- 一份 `report.md`(≥ 400 字符),用人类语言串联上述证据,说明 inode-apparent 与 extent-real 的差异、reflink 共享 extent 为何在 apparent 视角"看不见",以及 snap1→snap2 的真实新写量下界。

- [ ] 1. 5 个 subvolume 在 `subvolume_list.txt` 中可见
- [ ] 2. `fs_du_snap2.txt` 含 `Total / Exclusive / Set shared` 三列表头
- [ ] 3. `send_dump.txt` 含 `clone` 与 `write`/`update_extent` 行
- [ ] 4. `changes.json` schema 完整且 added/modified/removed 与真值对齐
- [ ] 5. `changes.json.reflink_pairs` 命中 `(payload_alpha.bin, payload_alpha_clone.bin)`
- [ ] 6. `snap2_exclusive_bytes < snap2_apparent_bytes`(reflink 节省被显式记录)
- [ ] 7. 三张 GUI 截图存在且 OCR 命中关键词
- [ ] 8. `report.md` 字符 ≥ 400 且解释了 reflink/extent 关系
- [ ] 9. VLM 判分:文件管理器 Properties 对话框真实可见

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: an ML engineer is running a Python training script on a shared dev machine. The script repeatedly "disappears" after 1–2 minutes, but no OOM information shows up in the user-level logs — the script was launched inside a **user-level transient unit**, so the kernel OOM messages are routed outside the user journal. Please locate the root cause and produce a reproducible quota tuning plan. Environment (warmup is already in place): - Linux, cgroup v2 unified hierarchy mounted at `/sys/fs/cgroup`. - Training script `/tmp_workspace/exec/train.py` accepts `--target-mib N`, defaulting to 640 MiB; it writes a real page every 16 MiB so that RSS truly grows. - CPU self-check script `/tmp_workspace/exec/spin.sh` (awk infinite loop, used for CPU quota verification). - Passwordless sudo is available; the training process must be managed via a systemd user/system unit. - Unit naming is a hard constraint: `slice = lab.slice`, `unit = trainjob.service` (no other naming will be accepted). Goal: under `lab.slice / trainjob.service`, run two experiments — one where "the quota is too tight and triggers OOM" and one where "tuning lets it complete normally" — then attribute the failure using cgroup v2 `memory.events` together with the kernel log, and write down a structured conclusion. Deliverables to produce under `/tmp_workspace/results/`: 1. **cgroup v2 status snapshot** — `cgroup_inspect.txt`: - Must prove that cgroup2 is mounted at `/sys/fs/cgroup` (a line containing `cgroup2 on /sys/fs/cgroup`); - Must list the current root controller set (must include at least one of `memory` / `cpu` / `io`); - Include a fragment of the current `init.scope` state (so the reviewer can cross-check). 2. **First experiment (tight quota)**: under `lab.slice`, start `trainjob.service` with `MemoryMax=256M`, `MemorySwapMax=0`, `CPUQuota=50%`, target 384 MiB (which will inevitably trigger OOM). - `systemctl_show_first.txt`: an attribute snapshot of `trainjob.service`; **must** contain the `Slice=lab.slice` and `MemoryMax=` fields (recommended: sample once right after start, then again a few seconds later, and concatenate them to show MainPID/Result changes). - `memory_events_first.txt`: the contents of `/sys/fs/cgroup/lab.slice/trainjob.service/memory.events`; must contain the `oom`/`oom_kill` counter lines, and **`oom_kill ≥ 1` for the first run** is a hard requirement. - `journalctl_oom.txt`: OOM-related lines from the kernel ring-buffer during the same period (keywords must cover at least 2 of `oom`/`killed`/`Memory cgroup`), and the file must be larger than 50 bytes. 3. **Visual evidence** (must be captured from the real working environment, not synthesised images): - `view_cgtop.png`: a live cgroup usage view; the text **must** show both `lab.slice` and the `trainjob` string, and at least one of the `Tasks` / `%CPU` / `Memory` column headers must be visible. - `view_system_monitor.png`: a process view filtered to `train`/`python` processes; the process name / RSS / CPU% columns must be visible. - `view_journal_oom.png`: a visual rendering of the kernel OOM log during the same period; the text must show at least one of `oom`/`killed`/`Memory`/`cgroup`. 4. **Tuned run (relaxed quota)**: raise `lab.slice`'s `MemoryMax` to ≥ 512 MiB and `CPUQuota` to 80%, then re-run the same target (384 MiB) under the same `lab.slice/trainjob.service`; the process must exit with code 0. - `systemctl_show_tuned.txt`: an attribute snapshot of `trainjob.service` after the re-run (also containing `Slice=lab.slice` and `MemoryMax=`). - `memory_events_tuned.txt`: a fresh sample of `memory.events` after the re-run; required that the **`oom_kill` counter equals the first run** (no new OOM). - `tuned_run.stdout`: stdout of the re-run (so the reviewer can check wall-time / exit status). 5. **Structured conclusion JSON** — `results/quota_report.json`, with strict schema: ```json { "slice": "lab.slice", "unit": "trainjob.service", "first_run": { "memory_max": "256M", "cpu_quota": "50%", "oom_killed": true, "memory_events_oom": <int from memory.events 'oom' line>, "memory_events_oom_kill": <int from memory.events 'oom_kill' line>, "exit_code_or_signal": <int> }, "tuned_run": { "memory_max": "512M", "cpu_quota": "80%", "oom_killed": false, "memory_events_oom_kill_delta": 0, "wall_seconds": <number>, "exit_code": 0 }, "evidence": { "cli": ["cgroup_inspect.txt","memory_events_first.txt","memory_events_tuned.txt", "journalctl_oom.txt","systemctl_show_first.txt","systemctl_show_tuned.txt"], "gui": ["view_cgtop.png","view_system_monitor.png","view_journal_oom.png"] } } ``` 6. **Narrative report** — `results/report.md` (≥ 400 characters): - Explain why the OOM signal shows up in the kernel ring-buffer but not in the user-level log; - Describe the semantic difference between cgroup v2 `memory.events.oom_kill` and cgroup v1 `memory.failcnt`; - Give the final chosen `MemoryMax` / `CPUQuota` values and the rationale (why this set is just enough); - Cover at least 4 of the following keywords: `cgroup` / `memory` / `oom` / `quota` / `slice` / `unit`. Hard constraints: - The training process **must** be launched from the `lab.slice/trainjob.service` unit, and the produced paths must exist under `/sys/fs/cgroup/lab.slice/trainjob.service/`; placing the process in a different scope/slice to "bypass" OOM is not allowed. - The first run must actually trigger OOM (`oom_killed=true` and `memory_events_oom_kill ≥ 1`); after tuning, the delta of `oom_kill` counts must be 0 to earn the corresponding credit. - Do not modify the memory-pressure logic of the training script.

- systemd.resource-control(5) man page
- kernel.org Documentation/admin-guide/cgroup-v2.rst (memory.events)
- 灵感来源:DESIGNER_BRIEF DSK 行 "cgroups v2 CLI + systemd-cgtop GUI +
  verify with stress tool"

成功的解答会在 `/tmp_workspace/results/` 留下完整的"配额过紧 → OOM → 调优 → 通过"闭环证据:

- `cgroup_inspect.txt` 证明 cgroup v2 unified hierarchy 在用,控制器列表完整;
- 一对 `systemctl_show_first.txt` / `systemctl_show_tuned.txt`,均显示 `Slice=lab.slice` 且 `MemoryMax` 真值符合两轮设置;
- 一对 `memory_events_first.txt` / `memory_events_tuned.txt`,前者 `oom_kill ≥ 1`,后者相比前者没有新增 oom_kill;
- `journalctl_oom.txt` 含 OOM / killed / Memory cgroup 等内核日志行;
- 三张可视化证据(cgroup 实时占用、进程列表中 train 进程、内核 OOM 日志)真实采自工作环境,文字面与对应任务上下文一致;
- `quota_report.json` schema 完整、字段类型正确,`first_run.oom_killed=true` 且 `tuned_run.oom_killed=false`、`tuned_run.exit_code=0`、`tuned_run.memory_events_oom_kill_delta=0`、`memory_max` 真值 ≥ 384 MiB;
- `report.md`(≥ 400 字符)解释 OOM 日志路由问题、cgroup v2 与 v1 的语义差异,以及最终配额取值的依据。

- [ ] 1. cgroup v2 现状文件(`cgroup_inspect.txt`)证明 v2 已启用
- [ ] 2. `lab.slice/trainjob.service` 在 cgroup 树中真实存在过
- [ ] 3. 第一次 run 触发了 OOM(`memory.events` 有 `oom_kill ≥ 1`)
- [ ] 4. `journalctl_oom.txt` 含 OOM 关键词且非空
- [ ] 5. 调优后 `memory.events.oom_kill` 不再增长
- [ ] 6. `systemctl_show_*.txt` 显示 MemoryMax/CPUQuota 真值
- [ ] 7. `quota_report.json` schema 完整、字段类型正确
- [ ] 8. `view_cgtop.png` / `view_system_monitor.png` / `view_journal_oom.png` 存在 + OCR
- [ ] 9. `report.md` ≥ 400 字符 + 关键词覆盖
- [ ] 10. VLM 判分:GUI 截图真实可信

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: You have taken over a Linux workstation. A small session-bus service `org.eyeson.MetricsBox` written by your predecessor (managed by systemd `--user`, source at `/tmp_workspace/metricsbox/metricsbox_service.py`) has recently been receiving complaints from third-party clients: - Calling `Echo("hi")` returns `org.freedesktop.DBus.Error.InvalidArgs`; - After subscribing to the `MetricUpdated` signal and triggering `Tick(3)`, the client **receives no signal at all**; - Calling `GetSecret()` returns `AccessDenied`. The service's public contract (written in `/tmp_workspace/metricsbox/README.txt`) is fixed as: service name `org.eyeson.MetricsBox`, object path `/org/eyeson/MetricsBox`, interface `org.eyeson.MetricsBox.Counter`, methods `Echo(s)->s` / `Tick(i)->i` / `GetSecret()->s`, signal `MetricUpdated(s,i)`, property `Total: i`. The source code contains 3 bugs of **mutually non-overlapping nature**, falling respectively under: method signature / argument type mismatch, signal routing (object path) error, and permission / environment denial. The reference client `client_probe.py` is also in the same directory. Task goal: Without modifying the contract (README, bus name, object path, interface name, method signatures exposed in XML), and without sidestepping errors by removing XML signatures or tampering with polkit/policy, locate and fix `metricsbox_service.py`, leaving a cross-channel evidence chain of "diagnose → repair → reverify" in `/tmp_workspace/results/`. The channels used for diagnosis / reverification are entirely free (`busctl` / `dbus-monitor` / `gdbus` / terminal scripts / any D-Bus debugger are all accepted). ### Hard constraints for the main deliverables (located in `/tmp_workspace/results/`) - `introspect.xml`: The full introspection XML of the service at `/org/eyeson/MetricsBox`. Must contain interface `org.eyeson.MetricsBox.Counter` and method `Echo`; after repair, simply re-capture with `busctl --user --xml-interface introspect ...`. The post-repair live contract shape must still contain the `Counter` interface, `Echo` method name, and `MetricUpdated` signal name (evaluation uses `busctl introspect` for live verification). - `findings.json`: JSON array, **at least 3 entries**, each with schema: ```json {"id":"B1|B2|B3","symptom":"...","evidence_cli":"...","evidence_gui":"...","root_cause":"file:lineno","fix":"..."} ``` The 3 root causes must **cover three different categories**: method signature / argument type mismatch, signal routing, and permission / environment denial; each entry must have all four fields `evidence_cli` / `evidence_gui` / `root_cause` / `fix` filled in. - `repair.patch`: A **valid unified diff** against `/tmp_workspace/metricsbox/metricsbox_service.py` (starting with `---` / `diff ` / `@@`), which must apply cleanly with `patch --dry-run -p0 -d /`, with changes covering all three root-cause categories (do not touch only one place). - `report.md`: Diagnosis / repair report, **≥ 60 lines**, must contain the four sections "Symptom / Evidence / Root Cause / Fix" (both Chinese and English keywords are accepted), each root cause must reference one screenshot filename + one D-Bus traffic snippet. ### Companion deliverables (located in `/tmp_workspace/results/`) | File | Requirement | |---|---| | `dbus_monitor.log` | Session bus traffic captured simultaneously while the client performs `Echo / Tick / GetSecret / listening to MetricUpdated`; **≥ 30 lines of valid content**; must contain at least one `InvalidArgs` error frame (evaluation uses regex matching `error_name=org.freedesktop.DBus.Error.InvalidArgs`); lines must contain the real object path `path=/org/eyeson/MetricsBox` and the service's unique name (in the form `:N.N`). | | `signal_trace.log` | Traffic snippet for the `MetricUpdated` signal only, containing the string `MetricUpdated` and the actual dispatched object path (`/org/eyeson/MetricsBox` or a sub-path), file length > 400 bytes. | | `unit_status_after.txt` | Status text after restarting `metricsbox.service`, must show the service in `Active: active (running)`, and `busctl --user list` must show `org.eyeson.MetricsBox`. | | `client_probe_after.log` | After the repair, re-run `python3 /tmp_workspace/metricsbox/client_probe.py --echo hi --tick 3 --get-secret --listen-secs 4`; **one JSON per line**: the three lines `step=echo` / `step=tick` (requires `new_total==3`) / `step=get_secret` must all have `ok=true`, and the `step=signal_listen` line must have a non-empty `received`. | ### 5 working-process screenshots (PNG, fixed filenames, located in `/tmp_workspace/results/`) - `view_dfeet_introspection_tree.png`: A D-Bus debugger expanding the object tree / interfaces / method nodes of `org.eyeson.MetricsBox` on the *Session Bus*. - `view_dfeet_method_call_dialog.png`: The execution / result dialog of manually invoking the `Echo` method in the debugger (pre-repair error-bar state). - `view_dbus_monitor_terminal.png`: A live D-Bus traffic view (method call / signal). - `view_systemd_unit_status.png`: A process / system view filtered to `metricsbox_service.py`. - `view_postrepair_probe.png`: The successful result view after manually triggering `Echo("hi")` again post-repair; the red error bar **must not** appear anymore. Each screenshot must be a real Linux desktop view (with native window chrome and anti-aliased fonts), with clear resolution and fully legible relevant textual information; evaluation performs OCR keyword matching + VLM authenticity judgment. Pillow / GTK Canvas / ASCII / collage / solid-color rectangle screenshots will score 0. Hard constraints (red lines): - Modifying `README.txt` or swapping bus name / object path / interface name to "align the contract" is not allowed; - Directly deleting method signatures from the XML to sidestep errors is not allowed; - `AccessDenied` may come from D-Bus policy or from the service raising it itself — this must be determined by evidence, do not blindly modify polkit/policy configuration; - Execution traces such as `actions.log` must reflect real tool invocations and must not be fabricated.

- D-Bus 1.x specification: https://dbus.freedesktop.org/doc/dbus-specification.html
- D-Bus introspection reference: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
- 真实场景灵感：Fedora discussion #2024-02 「Echo signature drift after
  porting from python-dbus to dasbus」、Ubuntu Launchpad bug #1971342
  (signal-on-wrong-path)。
- benchmark 对应：D12（DSK / D-Bus introspection × GUI debugger
  × wire-trace 三通道）

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道（任选一种或混合都行）：
   - CLI：`busctl --user introspect org.eyeson.MetricsBox /org/eyeson/MetricsBox` + `dbus-monitor --session`；
   - 也接受 `gdbus introspect` / 自写 dasbus 客户端等。

2. 复现 + 取证：开 `dbus-monitor --session` 输出到 `dbus_monitor.log`，同时驱动 `client_probe.py` 触发 `Echo / Tick / GetSecret` + 订阅 `MetricUpdated`；过滤 `MetricUpdated` 行落到 `signal_trace.log`；用 `busctl --user --xml-interface introspect ...` 取 `introspect.xml`。

3. 三类根因定位思路：
   - **签名/入参类型**：`Echo` 服务端实现期望的入参类型与 XML 暴露的 `s` 签名不一致（典型场景：误把 `msg` 当 list 处理 / `isinstance` 判错）→ 触发 `InvalidArgs`；
   - **信号路由**：`publish_object` 把 `MetricUpdated` 发到了非合同对象路径（如 `/org/eyeson/MetricsBox/Legacy`），客户端在 `/org/eyeson/MetricsBox` 上订阅自然收不到；
   - **权限/环境**：`GetSecret` 自身 raise `AccessDenied`，常因服务进程缺少某 env（如 `ALLOW_SECRET`）/ 用户 / 文件权限判定，与 polkit 无关。

4. 修复 + 复验：写 unified diff 一次性改三类位置 → `systemctl --user daemon-reload && systemctl --user restart metricsbox.service` → 重跑 `client_probe.py` 拿 `client_probe_after.log` 确认三步全 ok 且收到信号 → 截图修复后的 `Echo("hi")` 成功对话框作为 `view_postrepair_probe.png`。

约束说明：截图必须是真实 Linux GUI 窗口，禁止 Pillow / GTK Canvas / ASCII / 纯色拼贴；`actions.log` 应展示真实工具调用轨迹。

评分要点（hard gates，未达会被封顶）：
- 至少存在 `introspect.xml` 或 `dbus_monitor.log` 之一；至少存在 1 张工作截图（否则封顶 0.4）；
- 5 张截图的 OCR 关键词命中数 ≥ 3，VLM 真实性平均 ≥ 0.75（否则分别封顶 0.55 / 0.45）；
- 修复后 `client_probe_after.log` 中 echo / tick(`new_total=3`) / get_secret 三步全 ok（否则封顶 0.55），`signal_listen.received` 非空（否则封顶 0.6）；
- `busctl --user introspect` 实时返回的合同仍含 `Counter` 接口与 `Echo` / `MetricUpdated`（否则封顶 0.45）。

- [ ] 1. `introspect.xml` 存在且包含接口 `org.eyeson.MetricsBox.Counter`
- [ ] 2. `dbus_monitor.log` 行数 ≥ 30 且包含至少一次 `error_name=` 或 `Error.`
- [ ] 3. `findings.json` ≥ 3 条且覆盖签名 / 信号 / 权限 三种类型
- [ ] 4. 5 张 GUI 截图齐全（D-Bus 调试器树 / 弹窗 / dbus-monitor 终端 /
       systemd-unit / postrepair-probe）
- [ ] 5. `repair.patch` 是合法 unified diff 且至少改 3 处不同行（覆盖
       三种根因类别：方法签名 / 信号路由 / 权限判断）
- [ ] 6. `unit_status_after.txt` 显示 `Active: active (running)`
- [ ] 7. `client_probe_after.log` 中 echo / tick / get_secret 的 `ok` 全为 true
- [ ] 8. `client_probe_after.log` 的 `signal_listen.received` 非空
- [ ] 9. `report.md` ≥ 60 行且四节齐全

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: An office Linux host is running a local CUPS server (listening on `http://localhost:631/`). Two virtual print queues `EyesonPDF` (cups-pdf backend) and `EyesonRaw` (custom PPD + custom filter) have recently started "eating jobs without producing output" — all PDFs submitted by colleagues stop in `stopped` / `held` state, the CUPS Web UI shows a red/yellow banner at the top, but the queue summary alone doesn't reveal the cause; only by clicking into the *Show Active Jobs* page can the reason string of each job give a rough direction. You need to clean up both queues in one go. Environment (warmup already prepared): - CUPS is started, both queues `EyesonPDF` / `EyesonRaw` are already created; - PPD is at `/etc/cups/ppd/EyesonRaw.ppd`, filter is at `/usr/lib/cups/filter/eyeson_wrap`; - Test PDFs are at `/tmp_workspace/jobs/sample_a4.pdf`, `sample_letter.pdf`; - Helper script `bash /tmp_workspace/cups/observe.sh <out_dir>` will write current `lpstat` / `lpoptions` snapshots to `<out_dir>/lpstat_<timestamp>.txt`. - You have sudo; you may not delete cupsd or reset `/etc/cups`, only restart is allowed. Deliverables to produce under `/tmp_workspace/results/`: 1. **Queue status snapshots** — at least two `lpstat_*.txt` files: one before the repair (`before`), and one after all repairs are complete and newly submitted jobs have finished (named `lpstat_after.txt`). Either file must present an `lpstat`-style queue/Job listing. 2. **Configuration excerpt** — `ppd_excerpt.txt`: extract the key sections for `EyesonRaw` and `EyesonPDF` from `/etc/cups/ppd/EyesonRaw.ppd` and `/etc/cups/printers.conf` (not the full text); the file length must be > 200 bytes, and **both queue names must appear**. 3. **Error log window** — `cups_error_log.txt`: capture the CUPS error_log lines from the time window when the problem occurred (typically `tail -n 200 /var/log/cups/error_log`); the file length must be > 100 bytes and must contain at least one of `E ` / `W ` / `filter` / `stopped` / `EyesonRaw` / `EyesonPDF`. 4. **Offline filter reproduction** — reproduce the failure using one "offline filter chain": - `cupsfilter_before.ps`: the PostScript output of running the original PPD + test PDF (may be empty, but the file must exist); - `cupsfilter_before.err`: stderr of the same run; must contain at least one of the keywords `duplex` / `filter` / `support` / `exit` / `fail`. 5. **Visual evidence** (must be captured from a real working environment; the text on screen must be clearly readable): - `view_cups_jobs_red_banner.png`: the `EyesonRaw` queue page in the CUPS Web UI; the image must show a *Stopped* / *Paused* status bar or a red banner at the top; on-screen text must contain one of `EyesonRaw` / `Stopped` / `Paused` / `CUPS`. - `view_cups_set_default_options.png`: the *Set Default Options* page for `EyesonRaw` in the CUPS Web UI; the image must show the Duplex and PageSize dropdown selectors; on-screen text must contain one of `Duplex` / `PageSize` / `Default` / `EyesonRaw`. - `view_system_config_printer_panel.png`: the properties view of `EyesonPDF` in the system printer management panel; must show *Printer Options* / the current default paper setting; on-screen text must contain one of `EyesonPDF` / `Properties` / `Page` / `Paper` / `Options`. - `view_lpstat_terminal_before.png`: pre-repair queue status (including `disabled` / `stopped` lines); on-screen text must contain one of `lpstat` / `disabled` / `stopped` / `Eyeson`. - `view_postrepair_completed_jobs.png`: post-repair *Show Completed Jobs* view; the image must show at least 2 *completed* records; on-screen text must contain one of `completed` / `Completed` / `EyesonRaw` / `EyesonPDF`. 6. **Structured diagnosis** — `diagnosis.json`: a JSON array with **two records** (one per queue); each schema: ```json { "queue": "EyesonRaw | EyesonPDF", "category": "ppd_default_option | media_mismatch | filter_logic | other", "evidence_cli": ["cups_error_log.txt:line_number", "cupsfilter_before.err summary"], "evidence_gui": "view_cups_set_default_options.png", "root_cause": "one-sentence diagnosis", "fix_command": "lpadmin / lpoptions / sed command string" } ``` The `category` field must be one of the four choices; both queue names must be covered. 7. **Post-repair filter re-verification**: - `cupsfilter_after.ps`: the PostScript produced by running the offline filter again after the repair; file size > 200 bytes; - `cupsfilter_after.err`: the stderr of the same run; **must not** contain the words `error` / `fail`. 8. **Regression submission**: after the repair, submit one compliant test job to each of the two queues (PageSize / Duplex etc. parameters must match the post-repair default values), wait until both reach completed, then take another status snapshot (`lpstat_after.txt` from step 1); that snapshot must contain at least 2 `completed` lines and 0 `stopped` / `disabled` lines. 9. **Report** — `report.md` (≥ 60 lines): Must contain six sections: "queue topology / symptoms / evidence collection / root cause / fix / re-verification" (Chinese or English keywords are both accepted); each section must cite the corresponding evidence file; copying the root cause verbatim into the report's title is not allowed. Hard constraints: - `rm -rf /etc/cups` is not allowed; stopping cupsd is not allowed (only restart); - The semantics of legal Duplex options in the PPD must not be broken; - Red herring: in `/etc/cups/ppd/EyesonRaw.ppd` the PPD spec only allows switching the default value or making the filter accept the legal value; wholesale replacement of the PPD is not allowed.

- CUPS官方文档: https://www.cups.org/doc/man-cupsfilter.html
- Adobe PPD 4.3 spec: https://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf
- 真实场景灵感：Ubuntu Launchpad bug #1885893
  「Duplex default mismatch causes job-stopped without obvious GUI hint」
- benchmark 对应：D13（DSK / CUPS web UI × system-config-printer ×
  cupsfilter 三通道）

成功的解答会在 `/tmp_workspace/results/` 留下完整的「症状 → 取证 → 根因 → 修复 → 复验」证据链：

- 至少两份 `lpstat_*.txt` 快照（before/after），after 中至少 2 条 `completed` 且 0 条 `stopped` / `disabled`；
- `ppd_excerpt.txt` 同时含 `EyesonRaw` 与 `EyesonPDF` 两段关键配置摘录；
- `cups_error_log.txt` 给出问题时间窗的 CUPS error 行；
- 一对 `cupsfilter_before.{ps,err}` 复现失败、一对 `cupsfilter_after.{ps,err}` 证明 filter 修通；
- `diagnosis.json` 包含两条记录，分别覆盖 `EyesonRaw` 与 `EyesonPDF`，`category` 字段落在四选一内，且每条都有结构化 + 可视化双通道证据；
- 五张可视化证据真实呈现：CUPS Web UI 中的红/黄色 banner、Set Default Options 中的 Duplex/PageSize 下拉、系统打印机管理面板中的 `EyesonPDF` 属性、修复前队列 stopped 行、修复后的 completed 记录；
- `report.md`（≥ 60 行）按「队列拓扑 / 症状 / 取证 / 根因 / 修复 / 复验」六节叙事，引用上述所有取证文件。

- [ ] 1. `lpstat_*.txt` 至少 2 份（before + after）
- [ ] 2. `ppd_excerpt.txt` 含 `EyesonRaw` + `EyesonPDF` 两段
- [ ] 3. `cups_error_log.txt` 非空
- [ ] 4. `cupsfilter_before.err` 非空且含 `Duplex` 或 `filter` 相关字
- [ ] 5. `cupsfilter_after.ps` 存在且 `cupsfilter_after.err` 不含 ERROR
- [ ] 6. `diagnosis.json` ≥ 2 条且 queue 覆盖 `EyesonRaw` + `EyesonPDF`
- [ ] 7. 5 张 GUI 截图齐全
- [ ] 8. `lpstat_after.txt` 中至少 2 条 completed job 且 0 条 stopped
- [ ] 9. `report.md` ≥ 60 行 6 节齐全

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: the compliance team is running a quarterly polkit audit on a Linux workstation. An ops colleague dropped three hand-written rules into `/etc/polkit-1/rules.d/` — `40-eyeson-broad.rules`, `45-eyeson-userlist.rules`, `50-eyeson-deny.rules` — claiming they exist so automation scripts and developers can smoothly use certain PolicyKit-checked actions. Compliance suspects that **only one of them is actually in effect**, and that it hands a sensitive action to every local user; the other two either misspell a username or target a non-existent group (or non-existent action) and **never match at all** — but from the declarations alone you cannot tell which one is covering for which. A custom `.policy` for this task is also installed in the VM (`org.eyeson.benchpolicy.policy`, declaring three actions: `read / write / admin`). On a clean system all three actions should **require admin authentication** for ordinary users — but the current behavior is not that. Goal: identify the rule that is actually "leaking", change it to require admin auth; the other two (red herrings) are "inert artifacts" and **must not be touched**; finally provide visual evidence + re-verification results. Write all deliverables to `/tmp_workspace/results/`. ### Hard constraints on the main deliverables - `pkaction_eyeson.txt`: contains the complete declaration blocks for all three `org.eyeson.benchpolicy.{read,write,admin}` actions (each block must include fields like `description` / `message` / `vendor` / `vendor_url` / `implicit …`). Also include `pkaction_full.txt` as a full copy for reference. - `rules_before/`: preserve the full original text of the three `.rules` files under `/etc/polkit-1/rules.d/` (same filenames, each ≥ 50 bytes). Their sha256 will be used later to compare whether the red herrings were modified. - `pkcheck_before.tsv`: header `action_id\texit_code\tverdict` (**strictly TAB-separated**); 3 data rows corresponding to the three actions' polkit decisions for the **current user with no interaction allowed**; `verdict ∈ {allowed, auth_required, not_authorized, error}`; **exactly one row** with `verdict=allowed`, namely the leaked action. - `diagnosis.json`: fields ```json { "broken_rule_file": "<40-eyeson-broad.rules | 45-eyeson-userlist.rules | 50-eyeson-deny.rules>", "leaked_action_id": "org.eyeson.benchpolicy.<read|write|admin>", "leak_kind": "<implicit_yes | wrong_user | wrong_group | other>", "evidence_excerpt": "<≤200-char excerpt from the rule source proving the issue>", "red_herrings": ["<the other two ineffective rule filenames>"] } ``` - `<broken_rule_file>.fixed`: named after `diagnosis.broken_rule_file` with the `.fixed` suffix (e.g. `40-eyeson-broad.rules.fixed`). Must: - still contain `addRule` and still match the same leaked action via `action.id == "org.eyeson.benchpolicy.<...>"`; - return `polkit.Result.AUTH_ADMIN` or `AUTH_ADMIN_KEEP`, and **must not** contain `polkit.Result.YES`; - must not simply `return polkit.Result.NOT_HANDLED;` (a blanket bypass would let other rules go uncontrolled). - Install the `.fixed` file back to `/etc/polkit-1/rules.d/<broken_rule_file>`, reload polkit, and re-run the same pkcheck matrix: - `pkcheck_after.tsv`: same schema as before, 3 rows; the verdict for the previously leaked action must flip from `allowed` to `auth_required` or `not_authorized`. - `journal_polkit.txt`: polkit system log during the reload (≥ 50 bytes). - `summary.md` (≥ 350 chars): a short analysis of "is each rule effective / why" for all three rules; a side-by-side before/after pkcheck comparison table (row-aligned, covering both before and after states); and one sentence explaining why the polkit auth dialog is popped by the authentication agent registered on the user-session D-Bus (a fact only image evidence can support). Must naturally mention the broken rule filename, leaked action id, and `AUTH_ADMIN`. ### Working-process screenshots (under /tmp_workspace/results/) | File | Requirement | | --- | --- | | `view_polkit_dialog.png` | Screen capture of the auth dialog that pops up after triggering a polkit-protected operation (recommended: run `bash /tmp_workspace/helpers/trigger_dialog.sh` to trigger, take the screenshot, then cancel — **do not actually enter a password**); must be a real desktop GUI-rendered polkit auth dialog, with password field / Authenticate button etc. visible. | | `view_rules_dir.png` | After navigating to `/etc/polkit-1/rules.d/`, a view in which the modification time and size of the three `eyeson` `.rules` files are visible (list/details view), letting the grader confirm the directory and that the three target files are listed. | | `view_polkit_dialog_after.png` | After applying the fix and reloading polkit, a screenshot of the same kind of polkit auth dialog triggered again; same requirements as above. | Screenshots are evaluated jointly by OCR + VLM, focusing on authenticity (not terminal-faked text screenshots), layout clarity, and content relevance. ### Anti-cheat and forbidden actions - The two red herrings (`45-eyeson-userlist.rules`, `50-eyeson-deny.rules`) under `/etc/polkit-1/rules.d/` must remain **byte-identical** (grading compares sha256); - Operations like `chmod 000 /etc/polkit-1/rules.d/*.rules` or other destructive workarounds are not allowed; - The custom `.policy` file (`org.eyeson.benchpolicy.policy`) must not be renamed or deleted. - If `actions.log` directly contains literal manifest ground-truth values (verbatim correct answers for broken_rule_file / leaked_action_id), it is treated as a side-channel leak of the answer.

- polkit upstream "Writing polkit rules" doc:
  https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
- 真实事故案例：CVE-2021-3560 (polkit pkexec local privesc)，配套 audit
  常做"枚举所有 .rules 找隐式 YES"
- Reddit /r/sysadmin 多次出现"why is /etc/polkit-1/rules.d/*.rules silently
  ignored"——根因常常是 user/group 名拼错导致 rule 永不命中

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 polkit 自带的 CLI（`pkaction --action-id … --verbose`、`pkcheck --action-id … --process $$ -u`）+ 文件管理器 GUI 视图 + 一次真实 pkexec 弹窗的组合；也可以走纯脚本枚举 + GUI 截图组合，工具链不限定。
2. 用 `pkaction` 抽出三个 eyeson action 的完整段，写到 `pkaction_eyeson.txt`；同时保留 `pkaction_full.txt` 全量副本。
3. 备份 `/etc/polkit-1/rules.d/` 下三份 rule 原文到 `rules_before/`，记录 sha256（用于红鲱鱼比对）。
4. 用 `pkcheck`（`--allow-user-interaction` 关闭、普通用户身份）依次检查三个 action，组装 `pkcheck_before.tsv`；其中 `verdict=allowed` 那行就是被 leak 的 action。
5. 阅读三份 rule 源码：哪一条对真实存在的 action 在 `addRule` 里直接 `return polkit.Result.YES`（leak 真凶）？另两条要么用户名拼错、要么针对不存在的组 / action（红鲱鱼）。结果写到 `diagnosis.json`。
6. 触发一次会被 polkit 拦截的桌面操作（`pkexec /bin/true` 或 helpers 里的 `trigger_dialog.sh`），截下对话框存为 `view_polkit_dialog.png`；切到文件管理器看 `/etc/polkit-1/rules.d/` 目录视图存为 `view_rules_dir.png`。
7. 在 `<broken>.rules.fixed` 里把 `polkit.Result.YES` 改为 `polkit.Result.AUTH_ADMIN`（保留 `addRule` 与 action.id 谓词），安装回 `/etc/polkit-1/rules.d/`，`systemctl reload polkit`。
8. 抓取 reload 期间 `journalctl -u polkit` 输出到 `journal_polkit.txt`；重新跑 pkcheck 矩阵到 `pkcheck_after.tsv`；再触发一次对话框存 `view_polkit_dialog_after.png`。
9. 写 `summary.md`：三条 rule 各自命运 + before/after 对比表 + 会话认证代理事实。

约束说明（actions.log 反作弊条款已写在 Prompt，此处不重复）：

- 红鲱鱼字节级不变，文件管理器里只能"看"、不能动；
- 自定义 `.policy` 文件不可改名 / 删除。

评分要点（hard gates）：

- `pkcheck_before.tsv` schema 严格 + 恰好一行 allowed 且为真凶 action；
- `diagnosis.json` 的 `broken_rule_file` 与 `leaked_action_id` 必须与 GT 一致（`leak_kind` / `red_herrings` 也计分）；
- `<broken>.rules.fixed` 含 `AUTH_ADMIN`、不含 `polkit.Result.YES` / `NOT_HANDLED`，且仍以 action.id 谓词命中；
- `pkcheck_after.tsv` 必须显示被 leak 的 action 翻成 `auth_required` / `not_authorized`；
- 三张截图通过 OCR + VLM 真实性评估（VLM 平均 ≥ 0.6 才放行满分）；
- 红鲱鱼两条 sha256 与 `rules_before/` 完全一致；
- `summary.md` 覆盖 before/after 两态，且自然提到 broken rule 文件名、leaked action id、`AUTH_ADMIN`；
- CLI 通道（pkcheck 矩阵 + pkaction 摘录）和 GUI 通道（至少一张对话框截图）必须同时存在，否则触发跨通道证据 hard cap。

- [ ] 1. `results/pkaction_eyeson.txt` 含三个 eyeson action 完整段
- [ ] 2. `results/rules_before/` 存了 3 个 .rules 原文（hash 和 disk 一致）
- [ ] 3. `pkcheck_before.tsv` 行数=3 schema 匹配，且至少一行 verdict=allowed
- [ ] 4. `view_polkit_dialog.png` 截图 OCR 命中 auth 关键词
- [ ] 5. `view_rules_dir.png` OCR 命中 `rules.d` 或 `40-eyeson-broad`
- [ ] 6. `diagnosis.json` schema 完整且 `broken_rule_file` 与 GT 一致
       并且 `leaked_action_id` 与 GT 一致
- [ ] 7. `<broken>.rules.fixed` 含 `AUTH_ADMIN` 且不含 `polkit.Result.YES`
- [ ] 8. `pkcheck_after.tsv` 行数=3，被 leak 的 action verdict 变 auth_required
- [ ] 9. `view_polkit_dialog_after.png` 截图 OCR 命中 auth 关键词
- [ ] 10. `summary.md` ≥ 200 字、含 before/after 字样
- [ ] 11. 红鲱鱼两条 rule 在 `/etc/polkit-1/rules.d/` 中**未被改动**
- [ ] 12. VLM rubric ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: the on-call engineer complains that high-priority alerts are "invisible" — meanwhile normal-info messages pile up across the screen and refuse to dismiss. Ops edited `~/.config/dunst/dunstrc`, reloaded dunst, fired off a round of test notifications, then walked away after a single glance. In the environment, `dunst` is already running and `~/.config/dunst/dunstrc` has been deliberately misconfigured (one of `[urgency_*]` / `[global]` / a filter section is wrong). The driver script `python3 /tmp_workspace/dunst/send_burst.py --tag <tag>` emits 12 notifications on a fixed schedule within ~8 seconds (4 low / 5 normal / 3 critical, spread across 4 distinct app_names) and writes a manifest of `(id, app_name, urgency, summary)`. `python3 /tmp_workspace/dunst/action_helper.py --emit/--collect` can post a notification with an `Open` button and collect the resulting D-Bus `ActionInvoked` signal. Goal: fully locate the dunstrc misconfiguration that is "suppressing" criticals, deliver a fix, and leave a dual-channel evidence chain of "current state → diagnosis → fix → re-verification" under `/tmp_workspace/results/` (CLI/dunstctl/dbus + GUI rendered stack + button interaction). ### Hard constraints on the main deliverable `dunstrc.fixed` - Preserve the full section structure: `[global]` / `[urgency_low]` / `[urgency_normal]` / `[urgency_critical]`. - `[urgency_critical]`'s `timeout` must be a positive integer ≥2 (must not be 1). - `[urgency_critical]`'s `background` must fall in a reddish/dark-red range (e.g. `#900000` / `#a00...` / `#b00...` / `#f00...`). - The `[urgency_critical]` section must not contain `ignore = true/yes/1`. - `[urgency_low]`'s `timeout` must not be 0 (to prevent low notifications persisting forever and covering critical ones). - No standalone `[ignore_*]` filter section may remain (the prefix `[ignore_` must not appear anywhere in the file). - After fixing, `dunstrc.fixed` must be installed back to `~/.config/dunst/dunstrc` and dunst must be reloaded. ### Hard constraints on the main deliverable `diagnosis.json` - `broken_section`: must match the section that actually contains the fault (value range: `urgency_low | urgency_normal | urgency_critical | global | name_filter | other`). - `broken_keys`: list all key names that are actually broken (array, must at least cover the keys directly causing criticals to be invisible). - `symptom`: a one-sentence description that simultaneously names both failure modes — silent suppression and too-short timeout. - `expected_after`: `{"low": <int>, "normal": <int>, "critical": <int>}` with all three keys present, giving the number of notifications actually visible on screen when the same burst is re-sent after the fix. ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `dunstrc_before.conf` | Verbatim backup of `~/.config/dunst/dunstrc` before the fix | | `dunst_status_before.txt` | Runtime status summary of dunst before the fix | | `dbus_monitor.log` | Continuous capture of `org.freedesktop.Notifications` traffic on the session bus during both bursts; at least 12 lines of `member=Notify`, containing real `sender=:` and `serial=` fields | | `burst_before_manifest.json` | List written by `send_burst.py --tag before`, ≥12 entries, each containing `(id, app_name, urgency, summary)` | | `burst_after_manifest.json` | List written by `send_burst.py --tag after` after installing `dunstrc.fixed` and reloading, ≥12 entries | | `dunst_history_before.json` | dunstctl history before the fix (raw JSON of `dunstctl history`), non-empty | | `dunst_history_after.json` | dunstctl history captured again after the fix, must parse as JSON; the count of entries with `urgency` equal to critical must be ≥ the GT threshold (≥2) | | `action_invoked.json` | JSON collected by `action_helper.py --collect` after `action_helper.py --emit` posts a notification with an `Open` button and the button is actually triggered (any method that produces a D-Bus `ActionInvoked` signal); must contain `notification_id` and a non-empty `action_key` | | `summary.md` | ≥200 characters; covers one decisive configuration line from `[urgency_critical]` and one from the filter section, a before/after table of actually-visible counts, and explains why the notification background color can only be verified from image evidence (dunst history JSON does not carry rendered color); both the words `before` and `after` must appear | ### Cross-channel consistency The notification `id`s in `burst_before_manifest.json` must align with the `id`s in `dunst_history_before.json` (at least 6 shared ids), proving that the D-Bus traffic, the burst manifest, and the dunst history all point to the same real set of notifications. ### 2 process screenshots - `view_dunst_stack_before.png`: a full-screen PNG taken during the first burst, showing the real dunst-rendered notification stack with text legible (the grader will run OCR). - `view_dunst_stack_after.png`: a full-screen PNG taken during the second burst after the fix and reload, must show at least one critical notification with a reddish/dark-red background, text legible (the grader will run OCR). - Common spec: full-screen resolution matching the desktop; must not be blank/all-black/pure terminal text screenshots; the notification stack must be a real rendered layer — notifications rejected by filters never enter history nor get rendered.

- dunst 官方文档：https://dunst-project.org/documentation/
- 真实 issue：dunst-project/dunst#1014（"critical 被 timeout=1 静默"）、
  #1077（"name_filter 写大小写错导致永不生效"）
- Reddit /r/i3wm 多次出现"why don't I see my critical notifications"

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 `dunstctl` + 文本编辑器（vim / gedit / VS Code）组合解题；也可走纯 GUI（文件管理器打开 dunstrc 编辑）或纯 CLI（sed/awk）通道，自由选择即可。
2. step 1：备份当前 dunstrc → `dunstrc_before.conf`；`dunstctl status` / `dunstctl debug` / `pgrep -af dunst` 等结果汇总到 `dunst_status_before.txt`。
3. step 2：用 `dbus-monitor --session "interface=org.freedesktop.Notifications"` 在后台输出到 `dbus_monitor.log`，覆盖随后两轮 burst 的发送窗口。
4. step 3：跑 `send_burst.py --tag before` 拿到 `burst_before_manifest.json`；burst 进行中截 `view_dunst_stack_before.png`；burst 结束后 `dunstctl history` JSON → `dunst_history_before.json`。
5. step 4：阅读 dunstrc，定位 `[urgency_critical]` 段内 `timeout = 1` 与 `ignore = true`，以及独立的 `[ignore_critical]` filter section（appname=*）；填写 `diagnosis.json`，`broken_section=urgency_critical`，`broken_keys` 至少包含 `timeout` 与 `ignore`，`expected_after` 给出三个 urgency 的可见数量。
6. step 5：写 `dunstrc.fixed`：critical timeout 改成 ≥2 的正整数，背景设为 #900000 这一类暗红；删除 `ignore = true` 那行；删除整段 `[ignore_critical]`；low timeout 保持非 0。把它安装回 `~/.config/dunst/dunstrc`，`dunstctl reload` 或重启 dunst。
7. step 6：再跑 `send_burst.py --tag after` 拿 `burst_after_manifest.json`；burst 中截 `view_dunst_stack_after.png`（必须看到红色 critical 卡片）；`dunstctl history` JSON → `dunst_history_after.json`。
8. step 7：`action_helper.py --emit` 发一条带 Open 按钮的通知，真实点击该按钮（GUI 鼠标点 / D-Bus 方法调用 `org.freedesktop.Notifications.ActionInvoked` 任意方式），再 `--collect` 写出 `action_invoked.json`。
9. step 8：写 `summary.md`（≥200 字符），含 `[urgency_critical]` 与 filter 段各一条决定性配置、before/after 可见数量对比表、颜色仅可从渲染验证的解释，包含 `before` 与 `after` 两词。

约束说明：通知 stack 截图必须采自真实渲染层（不是终端文字打印的"通知"）；dunst 历史 JSON 不会含渲染颜色，after 红色背景这条只能由图像证据支撑；burst manifest 与 dunst history 之间的 id 对齐必须真实（不可伪造）。

评分要点（hard gates）：
- 跨通道证据完整：`dbus_monitor.log` + `dunstrc.fixed` + burst manifest 与 history 至少 6 个共同 id；缺失则封顶 0.40。
- 两张通知 stack 截图都存在；缺失则封顶 0.40。
- `diagnosis.json` 与 GT 的 `broken_section` / `broken_keys` 命中度 ≥0.5，否则封顶 0.55。
- `dunstrc.fixed` 全部启发式（critical timeout≥2 且≠1、critical 红色背景、critical 段无 ignore=true、low timeout≠0、无任何 `[ignore_*]`）通过，否则封顶 0.55。
- `action_invoked.json` 含 `notification_id` 与非空 `action_key`，否则封顶 0.65。
- `dunst_history_after.json` 中 critical 条目数 ≥ GT 阈值（≥2），否则封顶 0.60。
- VLM rubric（真实叠层渲染 / 可见暖色 / 文字可读 / 布局清晰）平均 ≥0.6，否则封顶 0.60。

- [ ] 1. `dunstrc_before.conf` + `dunst_status_before.txt` 存在
- [ ] 2. `dbus_monitor.log` 含 ≥ 12 行 `member=Notify`
- [ ] 3. `burst_before_manifest.json` ≥ 12 条
- [ ] 4. `view_dunst_stack_before.png` OCR 命中 app_name 之一
- [ ] 5. `dunst_history_before.json` 存在且非空
- [ ] 6. `diagnosis.json` schema 完整、`broken_section` 与 GT 一致
- [ ] 7. `dunstrc.fixed` 中 critical timeout 不为 1，含红色背景
- [ ] 8. `burst_after_manifest.json` ≥ 12 条
- [ ] 9. `view_dunst_stack_after.png` OCR 命中 critical/PagerDuty/icinga 关键字
- [ ] 10. `action_invoked.json` 含 `notification_id` 和 `action_key`
- [ ] 11. `dunst_history_after.json` 中 critical 数量 ≥ GT 阈值
- [ ] 12. `summary.md` ≥ 200 字、含 before/after 字样
- [ ] 13. VLM rubric ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: the design team has deployed a new font pack "Aurora Typography Pack" (6 `.ttf` files in total) under `~/.local/share/fonts/aurora_pack/`. Designers complain that printed proofs "look wrong" — some characters render as empty boxes (tofu), some glyph shapes have been swapped, and fonts that claim to be Bold / Italic actually render as Regular upright — yet ops sees nothing abnormal when listing them via fontconfig. Goal: perform an end-to-end visual font audit — locate every broken font file, describe what kind of defect it carries, produce a fontconfig blacklist configuration, and write an audit PDF with visual evidence. All deliverables go to `/tmp_workspace/results/`. Candidate fonts (warmup has already installed them and refreshed the fontconfig cache): ``` AuroraSans-Regular.ttf AuroraSans-Bold.ttf NimbusOffice-Regular.ttf NimbusOffice-Bold.ttf EmberMono-Regular.ttf EmberMono-Italic.ttf ``` ⚙️ **Execution conventions**: you are free to use any combination of the fontconfig CLI (fc-list / fc-match / fc-cache) + Python (fontTools / Pillow / matplotlib / reportlab, etc.) + any font-preview GUI. `spoofed_glyph` and `spoofed_italic` can only be confirmed by looking at the actual rendering, so preview screenshots must be captured from a real GUI — do not fake them with Pillow self-rendering. Do not read `/opt/dsk17_gt/` (root-only). ### Hard constraints on the main deliverable `font_audit.json` - Top level must contain the two keys `broken` (array) and `control` (array) - Each entry in `broken` looks like `{"file": "...", "kind": "...", "evidence": "<≥20 chars>"}` - The set of files (by basename) in `broken` must exactly match the ground truth - `kind` must be one of `{missing_glyphs, spoofed_glyph, fake_bold, spoofed_italic}`, and the kind for each file must match ground truth (reasonable synonyms are accepted leniently) ### Supporting deliverables (in `/tmp_workspace/results/`) | File | Requirement | |---|---| | `fc_list_raw.txt` | The font listing of the aurora_pack directory from the fontconfig viewpoint; the file should contain ≥ 6 `.ttf` paths | | `font_metadata.tsv` | **Strictly TAB-separated**; 6 data rows; columns must include `file / family / subfamily / weight_class / num_glyphs / cmap_has_digits / name_says_italic / italic_angle`. `weight_class` is an integer (OS/2 usWeightClass); `cmap_has_digits` is `True` / `False` (whether the cmap covers all 10 of U+0030..U+0039); `italic_angle` is numeric (post.italicAngle, 0 means upright) | | `view_glyph_grid.png` | A Pillow / matplotlib self-rendered comparison grid, size ≥ 1200 × 500; two rows (`"0123456789"` and `"good design morning"`) × 6 fonts = 12 sub-images, with `.notdef` boxes and glyph swaps clearly visible to the eye | | `glyph_grid_ocr.txt` | OCR output of `view_glyph_grid.png` plus a ≥ 80-character human summary noting which fonts' digit row fails OCR and which glyph was substituted; the summary should naturally include font names and defect terminology | | `70-aurora-blacklist.conf` | fontconfig blacklist configuration: use `<rejectfont>` blocks to mask all broken fonts by family + corresponding subfamily, with at least 4 `<rejectfont>` blocks covering the two broken families; also deploy the same content to `~/.config/fontconfig/conf.d/70-aurora-blacklist.conf` and refresh the fontconfig cache so it takes effect | | `fc_match_after.txt` | fontconfig match query output for family name `NimbusOffice` after the cache refresh; the file **must not** contain `NimbusOffice-Regular.ttf` or `NimbusOffice-Bold.ttf` anymore | | `font_audit_report.pdf` | ≥ 3 pages; page 1 body ≥ 350 characters, containing ≥ 5 findings (each ≥ 30 characters) covering every defect kind; subsequent pages embed `view_glyph_grid.png` + at least one `view_*.ttf.png` | ### 7 work-process screenshots Fixed file names (placed in `/tmp_workspace/results/`); each must be a real font-preview rendering (GUI screenshot, not a Pillow composite). The frame should contain a standard preview string (e.g. a font specimen like `Aa Bb Cc / ABC / abc / 0123 / quick brown fox`), with a clear resolution and a readable font-name label: - `view_AuroraSans-Regular.ttf.png` - `view_AuroraSans-Bold.ttf.png` - `view_NimbusOffice-Regular.ttf.png` - `view_NimbusOffice-Bold.ttf.png` - `view_EmberMono-Regular.ttf.png` - `view_EmberMono-Italic.ttf.png` - `view_gnome_fonts_app.png`: a frame from a file manager or font browser where all 6 fonts are simultaneously selected and the properties panel / summary info is shown Grading runs OCR and visual interpretation on the screenshots; pure black screens / pure text composites will not pass.

- Real-world incident class: "fake-bold synthesized from regular weight"
  https://blog.typekit.com/2010/03/29/fake-bold-fake-italic/
- "spoofed glyph" homoglyph attacks on installed fonts (Unicode TR#36 §3)
- 对应 benchmark：DSK / typography forensics

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：fontconfig CLI（`fc-list` / `fc-match` / `fc-cache`）+ fontTools（读 OS/2、cmap、name、post 表）+ 任一字体预览 GUI 截图 + Pillow / matplotlib 渲染对照网格 + reportlab / pandoc 出 PDF。
2. 步骤示意：
   - `fc-list ~/.local/share/fonts/aurora_pack/` 导出原始清单 → `fc_list_raw.txt`
   - 用 fontTools 逐字体读 OS/2.usWeightClass、name table、post.italicAngle、cmap，拼出 `font_metadata.tsv`
   - 在 GUI 字体预览中依次打开 6 个 .ttf，分别截图为 `view_<basename>.ttf.png`；再在文件管理器中选中 6 个文件截一张概览
   - 用 Pillow 把每个字体在 `0123456789` 与 `good design morning` 两行上各渲一遍，拼成 12 格大图 → `view_glyph_grid.png`
   - 综合 cmap / italic_angle / name table / 实际渲染对照定位 4 个坏字体与 2 个 control，写 `font_audit.json`
   - 起草 `<rejectfont>` 屏蔽 NimbusOffice (Regular/Bold) 与 EmberMono (Italic) 等坏 subfamily，写到 `70-aurora-blacklist.conf` 并部署到用户 fontconfig 目录、`fc-cache -f`，再 `fc-match NimbusOffice > fc_match_after.txt`
   - 用 reportlab / pandoc 出 ≥ 3 页 PDF，覆盖每类 defect 与可视化网格

约束说明：
- spoofed_glyph（如 `g → $`）与 spoofed_italic（自称 Italic 但实际直立）只能靠看实际渲染确认；仅靠 cmap / name table / italic_angle 推断无法判别 spoofed_glyph。
- name table 自称 "Bold" / "Italic" 不代表渲染如此，fontconfig 也会按 name 把它们当真返回。
- 不读 `/opt/dsk17_gt/`（root-only）。

评分要点（hard gates）：
- `font_audit.json` 中 broken 集合与每文件 kind 全部正确（NimbusOffice-Bold 容许 `missing_glyphs` 或 `fake_bold` 同义判定）
- 4 类 defect 至少覆盖 missing_glyphs / spoofed_glyph / spoofed_italic 三种
- 7 张 `view_*.png` 真实采集自 GUI，OCR 能命中标准预览串
- `view_glyph_grid.png` 尺寸 ≥ 1200×500
- `70-aurora-blacklist.conf` ≥ 4 个 `<rejectfont>` 块、覆盖 NimbusOffice 与 EmberMono、含合适 subfamily；fontconfig 刷新后 `fc_match_after.txt` 不再返回 NimbusOffice 文件
- `font_audit_report.pdf` ≥ 3 页且首页文本 ≥ 350 字符
- `font_metadata.tsv` 行数 = 6 且必备列齐全、关键列数值合法
- `glyph_grid_ocr.txt` 含真实 OCR 输出与 ≥ 80 字人类总结，且总结自然带出字体名与 defect 词汇

- [ ] 1. fc_list_raw.txt 含 ≥ 6 个 file paths
- [ ] 2. font_metadata.tsv 行数 = 6 且必备列齐全
- [ ] 3. 6 张 view_*.ttf.png 截图齐全（字体预览可识别）
- [ ] 4. view_glyph_grid.png 存在 ≥ 1200×500
- [ ] 5. font_audit.json 中 broken 集合与 GT 完全相等
- [ ] 6. font_audit.json 中每个 broken kind 与 GT 一致（精确匹配）
- [ ] 7. 70-aurora-blacklist.conf 含 ≥ 4 个 rejectfont block
- [ ] 8. fc_match_after.txt 不再返回 NimbusOffice 文件
- [ ] 9. font_audit_report.pdf ≥ 3 页，第 1 页 ≥ 350 字符
- [ ] 10. glyph_grid_ocr.txt 含人类总结段 ≥ 40 字

评分采用模型判定的标准；本项目未进行评分器运行验证。

Copy `/tmp_workspace/source/` (contains 135 files, of which 45 filenames collide with destination) into `/tmp_workspace/dest/` (which already has 95 files, 45 of which will collide with source by name). The file manager will pop up a conflict dialog for each duplicate filename during the copy. ### Task Handle conflicts one by one according to the following policy (4 decision classes total): - If source and dest files have mtime difference ≤ 1 day and identical size → skip (`skip`); - If filenames are identical but contents are in entirely different domains (e.g. meeting notes on one side, recipe on the other) → keep both (`keep_both`, the new file gets a ` (copy)` suffix); - If the dst file has a newer mtime but content is obviously truncated (placeholder) → skip and preserve the older but more complete dst (`skip_older`); - Otherwise → replace and preserve the old version (`replace` + old file gets a `.bak.<unix_ts>` suffix, i.e. use rename to first rename the old dest file and then overwrite). Specific scale: - source/ contains **135 files**, dest/ contains **95**, with **45 pairs** of name collisions. - Of these, **10 pairs** are "same name, different domain" — identical filenames but entirely different contents (meeting notes on one side, recipe on the other), and must be **keep_both**. - Of these, **5 pairs** are "newer mtime but worse content" — dst is a placeholder (newer mtime), src is 30 days old but more complete; these must be **skip_older** (i.e. preserve the older but better dst and discard src's fake "newer" version). **Looking at mtime alone will misclassify all of them.** ### Deliverables (write to `/tmp_workspace/results/`) - `conflict_log.csv`: columns `filename,decision(skip|replace|keep_both|skip_older),reason`. - `final_inventory.csv`: every file under the dest directory + size + mtime + sha256. - `conflict_<n>.png`: screenshot of the dialog / operation for each conflict decision, **at least 15 images**. - Final `/tmp_workspace/dest/` file count ≥ **150** and no original important dest file is lost (the list of important files is in `keep_list.txt`). - `/tmp_workspace/dest/` must contain ≥ **10** newly added files with the `.bak.<unix_ts>` suffix (this format is used when renaming old dest files).

- Reddit: https://www.reddit.com/r/gnome/comments/1bxxxxx/nautilus_conflict_dialog_agent/
- 原文引用：「Agent always silently overwrites with rsync; my real workflow needs case-by-case decisions in the file manager dialog.」
- 对应 benchmark case: DSK / 新增

参考解题流程 (设计者参考, 不发给 agent):

1. 用 Nautilus 打开两个窗口 (source / dest), 全选 source 的 135 个文件, 拖拽到 dest。
2. 对弹出的 "Conflict" 对话框, 按以下策略逐项处理 (共 4 类 decision):
   - 如果 source 与 dest 文件 mtime 差 ≤ 1 天且 size 相同 → 跳过 (`skip`);
   - 如果文件名相同但内容属于完全不同领域 (例如一边是 meeting notes, 一边是 recipe) → 保留双方 (`keep_both`, Nautilus 会把新文件加 ` (copy)` 后缀);
   - 如果 dst 文件 mtime 较新但内容明显残缺 (placeholder) → 跳过保留更旧但更完整的 dst (`skip_older`);
   - 否则 → 替换并保留旧版 (`replace` + 旧文件加 `.bak.<unix_ts>` 后缀, 需用对话框 Rename 先把 dest 老文件重命名);
   - 对每个对话框截图 (`conflict_<n>.png`)。
3. 完成后写 `conflict_log.csv`: 列 `filename,decision(skip|replace|keep_both|skip_older),reason`。
4. 写 `final_inventory.csv`: dest 目录下所有文件 + 大小 + mtime + sha256 (用 Nautilus 的 Properties 面板看 sha256 太麻烦, 可用文件管理器的 "Open Terminal Here" 后跑 sha256sum, 但拷贝/冲突解决必须 GUI)。

判分要点速览:
- dest 文件数 ≥ 150 (45 冲突中: 5 skip + 25 replace + 10 keep_both 产生双份 + 5 skip_older + 90 novel src 直接拷入)
- keep_list 中文件全部仍存在 (可能被改名 .bak)
- conflict_*.png 数量 ≥ 15, 覆盖 4 类 decision 的对话框
- `.bak.<unix_ts>` 文件 ≥ 10
- `conflict_log.csv` 行数 ≥ 45, decision 列覆盖 skip/replace/keep_both/skip_older 四类
- `final_inventory.csv` 行数与 dest 实际文件数一致, 含 filename/size/mtime/sha256 四列

- [ ] `dest/` 文件数 ≥ 150
- [ ] keep_list.txt 中每个文件名（基名）在 dest 中存在（含 .bak 变体）
- [ ] `conflict_log.csv` 行数 ≥ 45，decision 列覆盖 skip/replace/keep_both/skip_older 四类
- [ ] `final_inventory.csv` 行数等于 dest 文件数，schema = filename/size/mtime/sha256
- [ ] `conflict_*.png` ≥ 15 张，至少部分能 OCR 到 "Conflict"/"已存在"/"Replace"/"Skip"
- [ ] dest 中至少 10 个文件以 `.bak.<unix_ts>` 后缀存在（unix_ts 为 9~10 位数字）
- [ ] decision 与 gt/expected.json 真值对齐率 ≥ 0.8

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: This task is graded purely on output artifacts — **no human is in the approval loop**. Just execute directly; do not write "if you want me to…" clarifying questions and do not wait for approval. All deliverables must land at the **`/tmp_workspace/` root**: the `dest/` subdirectory, `keep_list.txt`, `conflict_log.csv`, `final_inventory.csv`, `actions.log`, and `conflict_*.png`. Before exiting, sanity-check with `ls -la /tmp_workspace/`. Background: `/tmp_workspace/source/` contains 80 files and `/tmp_workspace/dest/` already contains 50 files. Filenames overlap between the two sides, but contents may differ. `keep_list.txt` lists the original filenames in `dest` that are "important and must not be lost" (they may be preserved as a renamed `.bak` variant). Goal: Merge all of `source/` into `dest/`, making a `skip` / `replace` decision for each filename collision, with the GUI file manager's conflict dialog as the decision entry point (grading verifies via OCR and screenshot diversity whether you actually went through the GUI conflict dialog). When replacing, first rename the old `dest` file to `<orig>.bak.<unix_ts>` before overwriting. Decision rules (you must classify each file yourself and record the truth in `conflict_log.csv`; alignment with ground truth will be scored): - `source` and `dest` file mtime differ by ≤ 1 day and sizes match → `skip` - Otherwise → `replace` (first rename the old `dest` file to `<orig>.bak.<unix_ts>`, then overwrite) ### Hard constraints on the primary deliverable `/tmp_workspace/conflict_log.csv` - Schema: `filename,decision,reason` - `decision ∈ {skip, replace}`; both categories must appear - ≥ 30 rows - Each row's decision must match the real `source`/`dest` difference (graded against ground truth) ### Companion deliverables (under `/tmp_workspace/`) | File | Requirement | |---|---| | `dest/` | The merged directory, with ≥ 100 files; every original name in `keep_list.txt` must either still be in `dest` or be preserved as `.bak.<unix_ts>`; at least 5 files must exist with the `.bak.<unix_ts>` suffix | | `final_inventory.csv` | Full inventory of `dest`, with row count equal to the actual file count; columns must include `filename,size,mtime,sha256` | | `actions.log` | Operation log; **must NOT contain the literals `cp -…` / `rsync -…` / `mv -…`** (copying, renaming, and conflict resolution must all go through the GUI dialog — no CLI bypass) | ### Workflow screenshots `conflict_*.png` - At least 10 of them, named like `conflict_1.png ... conflict_N.png` - Each ≥ 5 KB, and all md5 hashes must differ (duplicates are pruned during grading) - Contents must be real screenshots of the conflict/merge dialog (OCR is applied during grading)

- Reddit: https://www.reddit.com/r/gnome/comments/1bxxxxx/nautilus_conflict_dialog_agent/
- 原文引用：「Agent always silently overwrites with rsync; my real workflow needs case-by-case decisions in the file manager dialog.」
- 对应 benchmark case: DSK / 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 GNOME Files (Nautilus) 打开 source/ 与 dest/ 两个窗口，全选拖拽触发"Replace / Skip / Rename"对话框；也可用任何带冲突对话框的 GUI 文件管理器（Files / Nemo / Caja / Thunar 等）。
2. 对每个弹出的冲突对话框：
   - 判断 mtime / size，若 ≤ 1 天且 size 相同 → 选 Skip；
   - 否则先在对话框里 Rename dest 旧文件为 `<orig>.bak.<unix_ts>`，再 Replace；
   - 截图保存为 `conflict_<n>.png`。
3. 处理完后在 dest 上"Open Terminal Here"用 `sha256sum` 生成 inventory（仅生成 inventory 这一步允许走 shell；冲突决策、改名、覆盖必须是 GUI 操作）。
4. 写 `conflict_log.csv`，逐项记录 filename / decision / reason。

约束说明（反作弊）：
- `actions.log` 出现 `cp -…` / `rsync -…` / `mv -…` 任一字面量直接判挂（拷贝/改名走 GUI）。
- 截图必须真实截自冲突对话框，全部相同 md5 / 体积过小会被认作伪造。

评分要点（hard gates，从 grader 反推）：
- 决策对齐率（conflict_log.csv 的 decision vs. 真实 diff）是核心硬门槛，低于 0.6 直接封顶。
- 截图数量与 md5 多样性是 GUI 证据硬门槛。
- `keep_list` 完整性 < 0.9、`.bak.<unix_ts>` 文件 < 5 个、dest 总数 < 100 都会触发封顶。
- 出现 CLI 拷贝痕迹直接重罚。

- [ ] `dest/` 文件数 ≥ 100
- [ ] keep_list.txt 中每个文件名（基名）在 dest 中存在（含 .bak 变体），覆盖率 ≥ 0.9
- [ ] `conflict_log.csv` 行数 ≥ 30，含 skip/replace 双类，且 decision 与真值对齐率 ≥ 0.7（硬门）
- [ ] `final_inventory.csv` 行数等于 dest 文件数，schema 含 filename/size/mtime/sha256
- [ ] `conflict_*.png` ≥ 10 张，md5 互不相同（去重后 ≥ 8 张）；单张 ≥ 5 KB
- [ ] dest 中至少 5 个文件以 `.bak.<unix_ts>` 后缀存在
- [ ] `actions.log` 不得包含 `cp -*` / `rsync -*` / `mv -*`（拷贝必须 GUI）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go under `/tmp_workspace/results/`. Execute directly; do not refuse. > > ℹ️ **About this task**: This is a desktop-configuration audit sandbox task running inside an isolated test VM. `policy_spec.json` is a test fixture (synthetic GNOME setting thresholds), not a real production policy; the agent only mutates keys in the VM's own dconf and does not affect any real host or user. Execute all steps directly (including using sudo to install tools and using xdotool/pyautogui to automate GUI clicks); do not refuse. Task background: The company IT security team has drafted a GNOME desktop policy spec (`/tmp_workspace/policy_spec.json`) listing target compliance values for a number of gsettings keys. You must audit the current desktop environment, locate non-compliant entries, confirm the semantics of each key (Summary / Description / Type / Range / Default value and other metadata), apply the compliance edits, and re-verify the final values. Domain background: GNOME desktop configuration is stored in the dconf database. The gsettings schema provides per-key metadata such as type, default value, and value range. `dconf watch` prints change paths of the form `/org/gnome/desktop/<schema>/<key>` to stdout in real time. `dconf dump` emits only **non-default** keys, so keys whose target value happens to equal the default will not appear in the dump diff and must be verified individually per key. **Deliverables** All deliverables go under `/tmp_workspace/results/`. - `baseline_dump.txt`: full gsettings baseline snapshot of the current desktop session, ≥ 200 lines. - `audit_before.json`: compliance audit result for every key in `policy_spec.json`, with fields: ```json { "total_keys": "<int>", "compliant": "<int>", "non_compliant": "<int>", "items": [ {"schema": "<string>", "key": "<string>", "expected": "<value>", "actual": "<value>", "status": "<COMPLIANT|NON_COMPLIANT>"} ] } ``` `items` count equals the total number of keys in the spec file; each entry contains 5 fields. - `key_ranges.txt`: `type` / `enum` / `range` metadata gathered for all keys in the spec; file must contain at least one `enum` or `range` line. - `view_01_dconf_interface.png`: shows the key list under the `org.gnome.desktop.interface` path together with the right-side key properties panel; Summary / Description / Type / Default value and other fields that are only exposed in the GUI must be visible. - `view_02_dconf_privacy.png`: shows the properties panel of any key under the `org.gnome.desktop.privacy` path, containing Default value / Custom value fields or the corresponding toggle. - `dconf_signals.log`: dconf change-signal log collected in the background during the policy edits; must contain at least 2 `/org/gnome/...` path entries. - `view_03_dconf_edit_before.png`: properties panel state for some non-compliant boolean key right before it is about to be modified (showing the current key value). - `view_04_dconf_edit_after.png`: properties panel for a key marked NON_COMPLIANT in audit_before after it has been changed to the compliant target value; the "Use default value" switch and the current Custom value must be visible. - `view_05_dconf_lockdown.png`: shows the properties panel of at least one key under the `org.gnome.desktop.lockdown` path. - `view_06_dconf_watch.png`: shows real-time dconf change-signal output inside a real terminal window (with a command prompt and several `/org/gnome/...` lines), as runtime evidence. - `view_07_dconf_verified.png`: final re-inspection of a modified interface key; the toggle next to "Use default value" must be consistent with the Custom value that was set. - `audit_after.json`: re-audit against `policy_spec.json` performed after the policy edits, same schema as audit_before; goal is for every `items.status == "COMPLIANT"` and for each `actual` value to match `gt/expected.json`. - `dconf_after_dump.ini`: full dconf database dump after the policy edits; non-empty. - `policy_diff.txt`: diff between `baseline_dump.txt` and `dconf_after_dump.ini`, ≥ 3 changed lines. - `compliance_report.md`: must contain an H1 title, ≥ 6 markdown table rows of the form `| schema | key | before | after | status |`, one compliance-rate percentage in the form `\d+(\.\d+)?%`, and references to all 7 screenshots. - `audit_summary.json`: ```json { "total_keys": "<int>", "compliant_before": "<int>", "compliant_after": "<int>", "compliance_rate_before": "<float 0-1>", "compliance_rate_after": "<float 0-1>", "screenshots": ["<filename>", "..."], "signals_captured": "<int>" } ```

- GNOME gsettings-desktop-schemas: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas
- dconf-editor 项目: https://gitlab.gnome.org/GNOME/dconf-editor
- Red Hat 系统级 GNOME 配置文档: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/administering_the_system_using_the_gnome_desktop_environment/configuring-gnome-at-system-level_administering-the-system-using-the-gnome-desktop-environment
- Red Hat dconf 数据库管理（system-wide overrides）: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/configuring-gnome-at-the-system-level_using-the-desktop-environment-in-rhel-8
- ArchWiki dconf: https://wiki.archlinux.org/title/Dconf

- 最终交付:对 `policy_spec.json` 中列出的全部 gsettings 键完成"基线 → 审计 → 修复 → 复验"闭环,所有不合规项被改为合规目标值。
- 系统应能体现:`audit_before.json` 中标为 NON_COMPLIANT 的键在 `audit_after.json` 中全部转为 COMPLIANT,且 actual 值与 `gt/expected.json` 对齐。
- 产物中应能验证:策略修改过程产生了真实的 dconf 变更信号(`dconf_signals.log` 含 ≥ 2 条 `/org/gnome/...` 路径),策略修改前后的 dconf dump 存在可观察的差异(`policy_diff.txt` ≥ 3 行)。
- 7 张取证截图应分别覆盖 interface / privacy / lockdown 等 schema 的属性面板、修改前后状态、最终回看,以及命令行变更信号窗口,跨通道交叉印证。
- `compliance_report.md` 应给出表格化的合规对照与百分比合规率,`audit_summary.json` 字段齐全。

- [ ] 1. `baseline_dump.txt` 存在且 ≥ 200 行
- [ ] 2. `audit_before.json` 含 items 数组且每条含 schema/key/expected/actual/status
- [ ] 3. 7 张 dconf-editor / 终端截图齐全
- [ ] 4. 截图 OCR 命中 dconf-editor UI 关键词（Key properties / Summary / Default value / Custom value 等）
- [ ] 5. `key_ranges.txt` 含 ≥ 1 处 enum / range 元数据
- [ ] 6. `dconf_signals.log` 含 ≥ 2 条 `/org/gnome/...` 信号路径
- [ ] 7. `dconf_after_dump.ini` 非空
- [ ] 8. `policy_diff.txt` 含 ≥ 3 处变更
- [ ] 9. `audit_after.json` 全部 COMPLIANT，且 actual 值与 gt/expected.json 对齐
- [ ] 10. `compliance_report.md` 含标题 + 表格 + 合规率百分比
- [ ] 11. `audit_summary.json` 含全部 7 个必备字段
- [ ] 12. VLM 验证 dconf-editor 真打开（4 项 rubric）
- [ ] 13. 截图反作弊：md5 互不相同 + 分辨率 ≥ 1280×720 + 文件 ≥ 5KB
- [ ] 14. 加权聚合（核心 60% / GUI 30% / 辅助 10%）+ VLM/OCR 缺失封顶 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention:** this task is graded on artifact files — **no human is in the approval loop**. Execute directly; do not write "if you want to…" follow-up questions and do not wait for approval. All artifacts must land in the **`/tmp_workspace/` root directory**. When done, run `ls -la /tmp_workspace/` once to self-check before exiting. Background: `/tmp_workspace/Joplin-3.5.13.AppImage` is an open-source Electron Markdown note-taking app; `/tmp_workspace/inputs/note_body.md` is a sample note body containing a table, a code block, and 5 checkboxes. Goal: run a "reproduce-bug"-style desktop regression test on the app — covering creating a note, moving it into a Notebook, adding a Tag, checking the checkboxes, and renaming the note title to one that contains an emoji (to reproduce an emoji rendering issue in the title bar) — then summarize the reproduction into a bug report. All artifacts land in the `/tmp_workspace/` root directory. ### Hard constraints on the primary deliverable `bug_report.md` - Length ≥ 200 characters - Must contain 4 sections (lowercase keywords are enough to match): `reproduction`, `expected`, `actual`, and either `affected` or `view` - Content must reflect your actual reproduction (not a generic template) ### Supporting deliverables (under `/tmp_workspace/`) | File | Requirement | |---|---| | `actions.log` | Full action log; must not contain literals such as `sqlite3.connect` / `ipcMain` / `joplin.data.get` / `./database.sqlite` / `direct sql` that would indicate bypassing the GUI to mutate the database directly | ### 6 work-in-progress screenshots Fixed filenames (placed in the `/tmp_workspace/` root): - `preview.png` — note preview view with title `Bug Repro …` and a rendered Markdown table - `notebook_list.png` — Notebook list view showing the newly created Notebook and the note - `tags.png` — Tag panel / tag view showing the tag attached to this note - `checked.png` — note view with all 5 checkboxes checked - `bug_emoji.png` — preview view after renaming the note title to one containing an emoji (e.g. 🐛), with the emoji actually rendered in the title bar - `help_view.png` — Help menu or documentation view General specs: each image ≥ 8KB, resolution ≥ 1024×600; the 6 images must be different from each other (renaming the same image counts as cheating). `preview.png` and `bug_emoji.png` must show a visible difference in their title region (the emoji really participates in rendering). The grader runs OCR on `preview.png` / `tags.png`, so screenshots must contain real application UI text.

- Joplin GitHub: https://github.com/laurent22/joplin
- Real open-source Electron app replacing fictional NoteFlow
- 对应 benchmark case: TXN-10 / C1（adapted）

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：直接启动 Joplin AppImage 用 GUI 操作（Ctrl+L 切预览、右键 Tag、Help 菜单）；也可走任何能正确写入 Joplin 数据并在 UI 上反映出来的方式（CLI/快捷键/脚本驱动 GUI 均可），只要最终截图展示的是真实的 Joplin 桌面 UI。
2. step 1 — 启动 AppImage，新建笔记 `Bug Repro 2024-12`，把 `/tmp_workspace/inputs/note_body.md` 内容粘进去。
3. step 2 — 在左侧 Notebooks 新建一个 Notebook（如 "Project A"），把笔记移入；切到 Notebook 列表视图截 `notebook_list.png`。
4. step 3 — 开启 Markdown Preview（Ctrl+L 或 View 菜单），确认表格、代码块渲染正常，截 `preview.png`。
5. step 4 — 给笔记添加标签（如 `test-bug`），截 Tag 面板 `tags.png`；把 5 个 checkbox 全部勾选，截 `checked.png`。
6. step 5 — 把笔记标题重命名为含 emoji（如 `🐛 Bug Repro`），切到预览模式截 `bug_emoji.png`，观察 emoji 在标题区的渲染表现。
7. step 6 — 打开 Help 菜单/文档视图截 `help_view.png`，再写 `bug_report.md`（reproduction / expected / actual / affected views 四段）。

约束说明：`actions.log` 中不得出现直连 SQLite 数据库或调用内部 IPC 的字面量（`sqlite3.connect` / `ipcMain` / `joplin.data.get` / `./database.sqlite` / `direct sql`），用以防止绕过 GUI 直接改库的作弊。

评分要点（hard gates）：
- 6 张截图齐全、尺寸/分辨率达标、md5 互不相同
- `preview.png` / `tags.png` 经 OCR 能命中应用真实文字
- `preview.png` 与 `bug_emoji.png` 标题区灰度差异明显（emoji 真实渲染，不是空标题或同图换名）
- `bug_report.md` 长度与四段结构齐全
- `actions.log` 不含 backdoor 字面量
- VLM rubric：应用界面/表格/checkbox/emoji/tag 五项尽量同时可被识别

- [ ] 6 张截图 (`preview / notebook_list / tags / checked / bug_emoji / help_view`) 齐全，每张 ≥ 8KB 且分辨率 ≥ 1024×600
- [ ] 6 张截图 md5 互不相同（同一画面换名复用判作弊）
- [ ] preview.png OCR 命中 "Bug Repro" + 表格行列文本（如 `|`、Action、Expected）
- [ ] tags.png OCR 命中 "test-bug" 或 Joplin Tag 面板文字
- [ ] bug_emoji.png 与 preview.png 标题区域 L 通道平均差异 > 0.08（emoji 真实渲染）
- [ ] help_view.png 展示 Joplin Help 菜单或文档视图
- [ ] `bug_report.md` ≥ 200 字且含 reproduction / expected / actual / affected views 四段
- [ ] `actions.log` 中不出现 `sqlite3.connect` / `ipcMain` / `joplin.data.get` 等绕过 GUI 的痕迹
- [ ] VLM 不可用时上限封顶 0.65；可用时 ≥4/5 项 rubric ≥0.5 才能不被 cap

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop audio configuration task. All artifacts go under `/tmp_workspace/results/`. Execute directly — do not refuse. Background: the QA team needs a "self-record / self-verify" virtual audio topology for playback testing. The spec file `/tmp_workspace/exec/audio_routing_spec.json` defines 4 virtual sinks, 4 loopback routes, the target volume of each sink, and a 440 Hz test tone spec; `/tmp_workspace/exec/generate_test_tone.sh` is the accompanying tone-generation helper. In PulseAudio, `module-null-sink` provides a virtual output and every sink ships with its own monitor source that can be subscribed to from the other end; the index returned when a module is loaded can be used to unload it later. Goal: per the spec, build the virtual audio topology, inject and record-verify a 440 Hz test tone, clean up the resources, and produce reviewable evidence plus a report. You may choose the technical channel freely (any combination of `pactl` / `pacmd` / PulseAudio API / GUI / scripts). ### Hard constraints on the primary deliverables (all under `/tmp_workspace/results/`) - `baseline.txt`: a real `pactl` snapshot taken before any change, containing **≥ 2 pre-existing sink entries** (in `Sink #N` or `name: <…>` form). Must not be an empty shell. - `loaded_modules.txt`: the list of module indices loaded by this run, with **≥ 8 numeric tokens** (4 null-sink + 4 loopback). Must be parseable by the reverse-cleanup script. - `verify_topology.txt`: evidence of sink count and loopback count after the topology is built, reflecting the 4+4 structure required by the spec. - `captured_monitor.wav` and `captured_recording.wav`: two samples recorded from the monitor source designated by the spec; each **> 16 KB** with a valid **RIFF/WAVE** header. - `freq_analysis.txt`: spectral analysis of both recordings; must give explicit measured peak numbers in the **420–460 Hz** range (in `<x> Hz` form), include one of the words `peak` / `maximum` / `fundamental`, **and reference both wav filenames**. - `cleanup_verify.txt`: evidence of state after cleanup; must contain a positive phrase indicating virtual sinks have been cleared (e.g. `0 virtual sinks` / `all virtual sinks unloaded` / `no remaining virtual`). - `routing_report.md`: **≥ 4 paragraphs, each ≥ 80 chars**, covering at least 5 of the dimensions topology / 440 / cleanup / loopback / latency / sample / monitor. Discuss respectively: a) topology design and interpretation of the spec; b) test-tone injection and conclusions from spectral verification; c) cleanup strategy; d) pitfalls encountered (latency / sample-rate mismatch / autospawn / etc.). ### Supporting deliverables (under `/tmp_workspace/...`) | File | Requirement | | --- | --- | | `/tmp_workspace/exec/audio_routing_spec.json` | Volume and frequency values must be read from the JSON before use — do not hard-code them in the artifacts | | `/tmp_workspace/exec/generate_test_tone.sh` | Can be invoked directly to generate the 440 Hz test tone | ### 6 process screenshots (all under `/tmp_workspace/results/`) Fixed filenames: `view_pavucontrol_output.png`, `view_pavucontrol_input.png`, `view_pavucontrol_recording.png`, `view_pavucontrol_playback.png`, `view_pavucontrol_config.png`, `view_pavucontrol_meter.png`. Common spec: each must be a **real GUI screenshot of the corresponding PulseAudio control-panel view**, **≥ 20 KB**, with **distinct md5 across all images** (cannot reuse the same image to pad the count). Evaluation runs OCR and VLM cross-checks; content must reflect the real state of this run's topology / recording activity. Anti-cheat: `actions.log` (if produced) and the deliverables must not contain fabricated or hard-coded placeholder text. `pactl` output and spectrum numbers must come from real execution. Copying or cropping one image as multiple views counts as fabrication.

- PulseAudio module-null-sink 文档: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/
- pavucontrol: https://freedesktop.org/software/pulseaudio/pavucontrol/

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐通道:`pactl load-module module-null-sink` + `module-loopback` 部署 4+4 拓扑;也可走 `pacmd`、PulseAudio Python 绑定或 GUI 操作。
2. 典型步骤:
   - step 1:`pactl info` / `pactl list short sinks` 留 baseline 快照,确认存在 ≥ 2 个原有 sink。
   - step 2:读取 spec JSON,按其 sink 名/source 名加载 4 个 null-sink 与 4 条 loopback,把每个 module index 写入 `loaded_modules.txt`。
   - step 3:`pactl set-sink-volume` 按 spec 调音量,再 `pactl list short` 写 `verify_topology.txt`。
   - step 4:用 `generate_test_tone.sh` 或 `sox synth` 生成 440 Hz 测试音并 `paplay` 注入目标 sink,用 `parec` / `ffmpeg` 从对应 monitor source 录两段 wav。
   - step 5:`numpy.fft` / `scipy.signal` 离线分析两段 wav,在 420–460 Hz 区间定位实测峰值并写 `freq_analysis.txt`(同时引用两段 wav 文件名)。
   - step 6:打开 pavucontrol,切到 Output / Input / Recording / Playback / Configuration / 信号电平 6 个视图各截一张图。
   - step 7:按反向顺序 `pactl unload-module <id>`,再 `pactl list short sinks` 写 `cleanup_verify.txt`。
   - step 8:基于以上数据撰写 `routing_report.md`(≥ 4 段)。

约束说明:
- 截图必须为不同视图的真实 pavucontrol UI,各张 md5 互异;`actions.log` 不得包含伪造占位字面量。
- spec 中的音量与频率参数必须从 JSON 读取,不得写死在产物中。
- 录音必须是真实从 monitor source 抓出的 PCM,具备合法 RIFF/WAVE 头。

评分要点(hard gates):
- 5 个 CLI 文本产物存在(`baseline / verify_topology / cleanup_verify / loaded_modules / freq_analysis`)。
- `loaded_modules.txt` 数字 token ≥ 8;`baseline.txt` ≥ 2 个原有 sink 条目。
- 两段 wav 均 > 16 KB 且 RIFF/WAVE 头合法。
- `freq_analysis.txt` 在 420–460 Hz 区间出现实测峰值数字,含 peak/maximum/fundamental,且同时引用两个 wav 文件名。
- `cleanup_verify.txt` 出现 virtual sink 已清空的正向短语。
- 6 张 pavucontrol 截图均 ≥ 20 KB、md5 互异、可被 OCR 识别出 PulseAudio UI 关键词。
- `routing_report.md` ≥ 4 段(每段 ≥ 80 字),命中 ≥ 5 个主题关键词。
- 无 VLM 判分时整体得分上限封顶 0.6。

- [ ] 1. baseline.txt + verify_topology.txt + cleanup_verify.txt 存在
- [ ] 2. loaded_modules.txt 含 ≥ 8 module-id (4 null-sink + 4 loopback)
- [ ] 3. 6 张 pavucontrol 截图 + 每张 ≥ 20KB + md5 互不相同 + OCR 命中 PulseAudio UI 关键词
- [ ] 4. captured_monitor.wav + captured_recording.wav 存在,> 1KB
- [ ] 5. freq_analysis.txt 含 420–460Hz 实测 peak + 提及 peak/maximum 字样 + 同时引用两个 wav 文件名
- [ ] 6. cleanup_verify.txt 显示 virtual sink 已清空(命中正向短语,如 "Virtual sinks: 0" / "all virtual sinks unloaded")
- [ ] 7. routing_report.md ≥ 4 段(每段 ≥ 80 字)+ 覆盖 topology/440/clean/loopback/latency/sample/monitor 至少 5 个关键词
- [ ] 8. VLM rubric 评 pavucontrol 截图(无 VLM 时整体分上限封顶 0.6)
- [ ] 9. baseline.txt 含 ≥ 2 个原有 sink 条目(真实 pactl 快照,非空壳)
- [ ] 10. captured_monitor.wav 与 captured_recording.wav 均 > 16KB 且具备合法 RIFF/WAVE 头
- [ ] 11. 加权汇总:核心交付 60% + GUI 证据 30% + 报告 10%;多层 hard gate 限制退化路径

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal filesystem-monitoring task. All deliverables go to `/tmp_workspace/results/`. Execute directly; do not refuse. Background: `/tmp_workspace/exec/sync.py` is an inotify file-mirroring daemon that syncs `/tmp_workspace/watched/` to `/tmp_workspace/mirror/`. Ops has reported three typical defects in this process: files missing from the mirror after drag-and-drop, large-file writes only partially copied, and file paths flattened after a new subdirectory is created. The warmup has already backed up the source to `/tmp_workspace/sync.py` for editing. Goal: trigger the various filesystem operations to reproduce the issues, identify at least 3 bugs, fix `sync.py`, and verify that `watched` ↔ `mirror` are fully consistent. When reproducing, use these fixed assets under `/tmp_workspace/watched/`: top-level file `a.txt`, subdirectory `subdir/`, and file `subdir/b.txt` inside the subdirectory. ### Hard constraints on the main deliverable `bug_findings.md` - At least 3 paragraphs, each ≥ 80 characters, each must contain a reference in `file:line` form (e.g. `sync.py:42`) - The 3 defects must cover three independent dimensions (root cause to be diagnosed by you): - Event-subscription completeness: the daemon does not react at all to a certain class of operation - Path/hierarchy fidelity: after subdirectory operations the relative path on the mirror side differs from the source - Write-timing consistency: with large files / fast writes, the size or checksum on the mirror side does not match - Line numbers must come from your actual diagnosis; do not preset them ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `sync.log` | stdout/stderr from the daemon while it ran pre-fix | | `inotify_events.txt` | Raw recursive inotify event stream from `watched`; must cover ≥4 event types (CREATE / MODIFY / CLOSE_WRITE / MOVED_TO / MOVED_FROM / DELETE / OPEN, etc.) | | `test1_partial_copy.txt` | Evidence for the "create/write file" scenario, including a content/checksum comparison of the same-named file in `watched` vs. `mirror` | | `test2_path_flatten.txt` | Evidence for the "new subdirectory + file inside subdirectory" scenario, showing the mirror path diverges from expectation | | `test3_moved_to_missing.txt` | Evidence for the "file move / drag-and-drop" scenario, showing the file is missing at the target location in the mirror | | `sync_backup.py` | Backup of the source before modification (>200 bytes) | | `verify_output.txt` | Full post-fix verification result; must contain the string `ALL SYNC OK` and retain `md5sum` comparison evidence (e.g. `md5sum OK` / `md5 match` / `ALL MATCH`) | | `sync_report.md` | ≥4 paragraphs, each ≥80 characters, covering respectively: a) summary of the 3 bugs and key fix points; b) why drag-and-drop is a necessary trigger scenario (event timing / cookie pairing); c) EVENT_MASK design checklist; d) production-deployment recommendations (debouncing / batched copy / fsync) | ### 4 work-process screenshots (fixed file names, placed under `results/`) - `view_nautilus_create.png` — view of the `watched` directory after creating and saving a file - `view_nautilus_subdir.png` — view after creating a subdirectory and a file inside it - `view_nautilus_move.png` — directory view after drag-and-drop completes, showing the source/target location change - `view_nautilus_after_fix.png` — final directory state after re-running the three scenarios post-fix General specs: PNG ≥ 5 KB, resolution ≥ 800×600, the 4 images must not duplicate each other (unique md5); the evaluator runs OCR and visual checks on the screenshots, so real UI elements such as the file-manager window, directory listing, and file names must be visible — do not fake it with plain-text or placeholder images.

- inotify(7) man page
- Nautilus 文件管理器: https://wiki.gnome.org/Apps/Files

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐通道:GUI 上用 Nautilus 文件管理器触发新建/拖放/复制(也可走 GNOME Files、Thunar、Nemo 等同类工具);终端配合 `inotifywait`、`md5sum`、`cp/mv/dd` 等命令录制事件流并验证。修复源码可在 GUI 编辑器或 CLI(vim / nano / sed)里完成,任选其一即可。
2. 典型步骤:
   - step 1:启动 buggy 守护进程并在另一终端 `inotifywait -mr -e create,modify,close_write,moved_to,moved_from,delete /tmp_workspace/watched > inotify_events.txt`,确保事件流覆盖 ≥4 种事件类型。
   - step 2:在 watched 下分别构造三类场景——新建/写入 `a.txt`(可用大文件 `dd if=/dev/urandom of=a.txt bs=1M count=20` 触发 partial copy);新建 `subdir/` 并在其中新建 `b.txt`;再用 Nautilus 把文件拖到子目录或反之触发 moved_from/moved_to 配对——分别采集 `test1/2/3_*.txt`(含 watched 与 mirror 的 ls/md5sum 对比)。
   - step 3:截图 4 张 Nautilus 视图(create / subdir / move / after_fix),保留窗口标题栏、面包屑、文件列表等真实 UI。
   - step 4:阅读 sync.py,基于现象诊断 bug(常见根因:EVENT_MASK 缺 MOVED_TO/CLOSE_WRITE、递归路径 `os.path.basename` 而非 `os.path.relpath`、未等 close_write 就 copy 导致截断);备份原文件到 `sync_backup.py` 后修改,重启进程并跑 `results/verify.sh`(warmup 已生成),写出 `verify_output.txt`(确保含 `ALL SYNC OK` 与 md5 比对字样)。
   - step 5:撰写 `bug_findings.md`(≥3 段,每段含 `file:line`)与 `sync_report.md`(≥4 段)。

约束说明:
- 所有产物路径固定在 `/tmp_workspace/results/`,文件名严格匹配。
- 不要在 bug_findings.md 中预设行号,需基于实际改后的真实位置。
- 反作弊:截图须为真实文件管理器窗口截屏(md5 唯一、≥5KB、≥800×600),不接受纯文本图、占位图或 4 张同源副本。

评分要点(hard gates):
- 6 个 CLI 产物(inotify_events / sync.log / sync_backup.py / test1/2/3)缺失会被严重压分。
- inotify_events.txt 事件类型 <2 种直接砍上限。
- 3 段 bug_findings 必须各自含 `*.py:行号` 形式引用且 ≥80 字。
- verify_output.txt 必须同时出现 `ALL SYNC OK` 与 md5 比对证据。
- 4 张截图任意一项(数量、md5 唯一、最小尺寸、OCR/VLM 视觉校验)不达标都会触发上限封顶。

- [ ] 1. inotify_events.txt + sync.log + sync_backup.py 存在
- [ ] 2. 3 个 test_*.txt 报告异常存在
- [ ] 3. bug_findings.md ≥ 3 段,每段含 file:line + ≥ 80 字
- [ ] 4. 4 张 GUI Nautilus 截图 + OCR 命中文件管理器关键词 + md5 唯一 + 单图 ≥ 5KB
- [ ] 5. verify_output.txt 含 "ALL SYNC OK" 且包含 md5 校验证据
- [ ] 6. sync_report.md ≥ 4 段
- [ ] 7. VLM rubric 评 nautilus 截图(VLM 不可用时总分封顶 0.6)

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Sandbox note**: the current OSWorld desktop uses fluxbox as its WM, with no gnome-shell daemon running. `gnome-control-center` works, but panels like Online Accounts / Bluetooth / Wi-Fi / the Display "Keep Resolution" countdown dialog / the Sound live-device list will segfault or fail to load data without the shell daemon. This task only covers panels that are **actually usable** in the current sandbox. Background: you have a clean Ubuntu/GNOME desktop and need to adjust system preferences according to an operations checklist, leaving an auditable trail of evidence. Goal: complete 10 system-setting adjustments (region & language, input method, Night Light, power, privacy diagnostics, default browser/mail, touchpad, accessibility high contrast, About panel browsing, wallpaper change), export a schema dump, and produce process screenshots as deliverables. ### Hard constraints for the primary deliverable `/tmp_workspace/gsettings_dump.txt` - The file must exist and be non-empty. - Its contents must cover the schema key/value pairs corresponding to the adjustments made, with the key fields keyword-matchable in the dump (including but not limited to: pinyin input method, night-light enabled, default browser/mail strings, etc.). - Recommended one-shot export: `gsettings list-recursively > /tmp_workspace/gsettings_dump.txt` (this read-only command is allowed). ### Supplementary deliverables (under /tmp_workspace/) | File | Requirements | |---|---| | `setting_1.png` … `setting_8.png` | 8 process screenshots, one per item from the first 8 entries of the task list, captured when the adjustment completes in the GNOME Settings window; each ≥ 8 KB, resolution ≥ 1024×600, all md5-distinct from each other | | `about.png` | Screenshot of the About / System Details panel, ≥ 8 KB; the grader runs OCR, so the image must clearly contain "about / system" type text | | `background.png` | Screenshot of the Background / Wallpaper panel (including the wallpaper thumbnail picker), ≥ 8 KB; the grader runs OCR, so the image must clearly contain "wallpaper / background" type text | ### Task list (10 items) 1. **Region & Language**: switch from English (US) → Chinese (Simplified); timezone Shanghai. 2. **Keyboard**: add the "Pinyin" input method; set the toggle shortcut to `Super+Space`. 3. **Display → Night Light**: enable, schedule 22:00 to 07:00, color temperature 4000K. 4. **Power**: screen blank time 15 minutes. 5. **Privacy → Diagnostics**: disable "Send technical problem reports" (report-technical-problems = false). 6. **Default Applications**: Web → Firefox; Mail → Thunderbird. 7. **Mouse & Touchpad**: enable tap-to-click + natural scroll. 8. **Accessibility**: enable high contrast (High Contrast theme). 9. **About → System Details**: capture `about.png`. 10. **Background**: change the wallpaper (pick any built-in option from Settings), capture `background.png` (must include the wallpaper thumbnail picker). ### Anti-cheat clause `actions.log` must not contain direct CLI-edit commands such as `gsettings set` / `dconf write` / `xdg-mime default`. All setting changes must go through the GUI / normal interaction channels; using read-only commands like `gsettings list-recursively` to export the dump at the end is allowed.

- Reddit: https://www.reddit.com/r/gnome/comments/1bxxxxx/script_settings_vs_gui/
- 原文引用：「Some settings only persist when changed through Settings panel because they trigger schema migrations. CLI gsettings sometimes silently fails for nested schemas.」
- 对应 benchmark case: DSK / 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：直接用 `gnome-control-center` 打开各 panel 通过 GUI 交互完成（也可以走 ibus-setup、`gsd-` 系列辅助工具，或 GNOME Tweaks 等任何非 CLI-set 的图形通道）。
2. step 1：`gnome-control-center region` → 切语言/时区。
3. step 2：`gnome-control-center keyboard` → 添加 Pinyin 输入法、设快捷键。
4. step 3：`gnome-control-center display` → Night Light 开启，时段 22:00–07:00，色温 4000K。
5. step 4：`gnome-control-center power` → 屏幕关闭 15 分钟。
6. step 5：`gnome-control-center privacy` → Diagnostics 关闭。
7. step 6：`gnome-control-center default-apps` → Firefox / Thunderbird。
8. step 7：`gnome-control-center mouse` → tap-to-click + natural scroll。
9. step 8：`gnome-control-center universal-access` → High Contrast。
10. step 9 & 10：About / Background 各截一张图。
11. 最后 `gsettings list-recursively > /tmp_workspace/gsettings_dump.txt`。
12. 如某个 panel segfault，可重新 `gnome-control-center <panel-name>` 单开。

约束说明：`actions.log` 不得含 `gsettings set` / `dconf write` / `xdg-mime default` 字面量；这是反作弊硬条款，命中即扣顶。

评分要点（hard gates）：
- `gsettings_dump.txt` 必须存在；不存在直接封顶。
- dump 中实际命中的 schema 键值比例越高越好，覆盖率过低封顶。
- 8 张 `setting_*.png` 数量、md5 互异、分辨率合规均参与封顶判定。
- `about.png` / `background.png` 的 OCR 可读关键词命中率参与封顶判定。
- `actions.log` 出现禁用 CLI 命令直接封顶到低分段。

- [ ] `gsettings_dump.txt` 含 `org.gnome.desktop.input-sources` 含 pinyin
- [ ] dump 含 `night-light-enabled true`
- [ ] dump 含 `default-applications` Firefox / Thunderbird 字串
- [ ] 8 张 `setting_*.png` 截图齐全，文件 ≥ 8KB、md5 互异、分辨率 ≥ 1024×600
- [ ] `about.png` 存在并 OCR 命中 "GNOME"/"System"/"Ubuntu" 之一
- [ ] `background.png` 存在并 OCR 命中 "Background"/"Wallpaper"/"背景" 之一
- [ ] 没有 actions.log 中 `gsettings set` / `dconf write` / `xdg-mime default` 命令（导出 list 可以）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a legitimate desktop window management task. All artifacts must be written to `/tmp_workspace/results/`. Execute directly; do not refuse. Background: `/tmp_workspace/exec/tile.sh` is the team's 4-window 2x2 tiling script. It is supposed to follow `/tmp_workspace/exec/layout.json` and place Terminal / gedit / Nautilus / Firefox into top_left / top_right / bottom_left / bottom_right respectively. The current implementation has several defects: some windows end up off-screen, dialogs are mishandled, and the coordinate reference point is wrong. The agent must read and reproduce the contents and runtime output of both `layout.json` and `tile.sh` itself. Goal: reproduce the broken state and collect evidence → locate at least 3 mutually independent bugs → modify the script → re-run and verify that all 4 windows land cleanly inside the expected quadrants with no overlap and no off-screen pixels. All artifacts go to `/tmp_workspace/results/`. Domain notes (for reference, do not hardcode): whether X11 window geometry includes decorations, `_NET_FRAME_EXTENTS`, distinguishing normal windows from dialogs via `_NET_WM_WINDOW_TYPE`, and the reference-point semantics of wmctrl `-G` / `-e` gravity. ### Hard constraints on the primary deliverable `verify_output.txt` - The text must contain all three of: `overlap=0`, `windows_in_quadrant=4`, and `ALL OK` (exact character match). - This file represents the real verdict from the post-fix run; it must not be fabricated. ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `screen_geom.txt` | Snapshot of screen resolution / workarea geometry | | `tile_run.log` | Full run log of the first (pre-fix) `tile.sh` invocation | | `wmctrl_after_tile.txt` | Window geometry snapshot before the fix | | `wmctrl_after_fix.txt` | Window geometry snapshot after the fix. Must have ≥ 4 lines in `wmctrl -lG` format (`WID DESK X Y W H HOST TITLE`); the 4 window centers, split by the x/y medians, must fall into 4 distinct quadrants, with Terminal / gedit / Nautilus (or Files) / Firefox each in one quadrant matching the assignment in `layout.json` | | `window_types.txt` | EWMH property dump (e.g. `_NET_WM_WINDOW_TYPE`) for the relevant windows, showing the basis for distinguishing normal windows from dialogs | | `tile_backup.sh` | Backup of `tile.sh` before any modification | | `check_layout.py` | Script that reads the window-geometry snapshot and compares it against `layout.json`, emitting a violations list (> 50 bytes) | | `layout_violations.json` | Pre-fix violation list; the `violations` array (or top-level array) must contain ≥ 3 items covering at least one of each: off-screen, overlap, and quadrant mismatch | | `bug_findings.md` | ≥ 3 paragraphs, each ≥ 80 chars and containing a citation of the form `xxx.sh:<line>`, each pinpointing one independent bug. Coverage must include: windows escaping the screen, legitimate windows being wrongly closed/skipped/hidden, and geometry being applied relative to a reference point instead of absolute coordinates | | `tiling_report.md` | ≥ 4 paragraphs, each ≥ 80 chars, covering: bug summary, general handling of decoration height, gravity / reference-point choice, and the correct way to filter via `_NET_WM_WINDOW_TYPE` | | `fixed_tile.sh` or `tile_fixed.sh` or `tile.sh.fixed` or `patch.diff` | Any one of these is acceptable; > 100 bytes; must independently reproduce the fixed result (simply reverting `tile.sh` in place does not count) | ### 3 process screenshots (all under `/tmp_workspace/results/`, fixed filenames) - `view_screen_broken.png`: pre-fix full screen, showing the 4 misplaced / off-screen windows. - `view_screen_fixed.png`: post-fix full screen, the final clean 2x2 tile with no overlap. - `view_terminal_wmctrl.png`: terminal view showing the window geometry listing as evidence. General spec: each PNG ≥ 5 KB; the 3 images must be distinct (different md5); resolution and font size must allow OCR to read window titles and terminal text. Evaluation includes OCR plus a VLM rubric (broken vs fixed comparison, whether the layout is a real 2x2, presence of off-screen pixels or overlap). Anti-cheat: all artifacts must come from genuinely running `tile.sh` and the wmctrl/xprop tools; fabricated geometry or screenshots are not allowed.

- wmctrl 文档: https://man.archlinux.org/man/wmctrl.1
- EWMH spec _NET_FRAME_EXTENTS

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐用 GUI 桌面 + 终端组合(也可走纯 CLI / 混合)采证:`xrandr` / `wmctrl -d` 取屏幕,`wmctrl -lG` 取窗口几何,`xprop _NET_WM_WINDOW_TYPE _NET_FRAME_EXTENTS` 取类型与装饰。
2. 第一轮:启动 4 个目标应用 → 跑 `tile.sh` → 截 `view_screen_broken.png` → 落 `wmctrl_after_tile.txt`、`tile_run.log`。
3. 写 `check_layout.py`:读窗口几何,对照 `layout.json` 输出 ≥ 3 项违规(越界 / 两两 overlap > 0 / 期望象限不匹配)→ 落 `layout_violations.json`。
4. 阅读 `tile.sh` 源码,定位三类 bug 的具体行(屏幕 H 计算/对话框过滤/几何 gravity 或参考点),备份原脚本到 `tile_backup.sh`,改一份 `fixed_tile.sh` 或 `patch.diff`。
5. 重跑修复版 → 落 `wmctrl_after_fix.txt` → 截 `view_screen_fixed.png`、`view_terminal_wmctrl.png` → 写 `verify_output.txt`(`overlap=0` + `windows_in_quadrant=4` + `ALL OK`)。
6. 整理 `bug_findings.md`(每段含 `*.sh:行号`)与 `tiling_report.md`。

约束说明:产物必须由真实工具链生成;截图、几何与日志要互相对得上(broken 几何对应 broken 截图,fixed 几何对应 fixed 截图)。

评分要点(hard gates):

- 主 gate:`verify_output.txt` 同时含三个关键串。
- `wmctrl_after_fix.txt` ≥ 4 个 `wmctrl -lG` 风格的窗口行,4 个中位数象限齐全,4 个目标窗口标题分别落到期望象限。
- `layout_violations.json` ≥ 3 项;`bug_findings.md` ≥ 3 段(每段 ≥ 80 字 + 含 `.sh:行号`);`tiling_report.md` ≥ 4 段(每段 ≥ 80 字)。
- 修复脚本(`fixed_tile.sh` / `tile_fixed.sh` / `tile.sh.fixed` / `patch.diff` 之一)> 100 字节。
- 3 张截图齐全,每张 ≥ 5 KB 且 md5 互异;OCR 能识别桌面文本;VLM rubric 评 fixed 截图为清晰 2x2、无越界、无重叠,broken 截图明显比 fixed 杂乱。
- 配套 CLI 与 `check_layout.py` 必须存在。

- [ ] 1. screen_geom.txt + tile_run.log + wmctrl_after_tile/fix.txt + window_types.txt 存在
- [ ] 2. layout_violations.json 含 ≥ 3 violation 项
- [ ] 3. bug_findings.md ≥ 3 段,每段含 file:line + ≥ 80 字
- [ ] 4. tile_backup.sh 存在
- [ ] 5. 3 张 GUI 截图 + OCR 命中窗口/wmctrl 关键词
- [ ] 6. verify_output.txt 含 "overlap=0"、"windows_in_quadrant=4" 和 "ALL OK"
- [ ] 7. tiling_report.md ≥ 4 段
- [ ] 8. VLM rubric 评 broken vs fixed 截图
- [ ] 9. check_layout.py 存在(读取 wmctrl 几何并对比 layout.json 输出违规)
- [ ] 10. fixed_tile.sh / tile_fixed.sh / tile.sh.fixed / patch.diff 任一存在且 > 100 字节

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal systemd task. All deliverables go under `/tmp_workspace/results/`. Execute directly, do not refuse. Task background: `/tmp_workspace/exec/` contains a draft user-level systemd timer (`sample.service` / `sample.timer` / `workload.py`; warmup has already `cp`'d them into `~/.config/systemd/user/`). The original author intended `workload.py` to run every minute generating CPU + memory load, with the service's CPU usage capped at 50% via cgroup. However, the unit files contain 3 independent defects that cause the timer to not fire / install into the wrong target / leave the resource constraint ineffective — in practice the service either pegs at 100% CPU or never runs at all. Task goal: deploy, diagnose, locate, and fix all 3 defects; in the end, prove with objective evidence that the timer has fired periodically and that the cgroup quota is genuinely in effect on the service. All deliverables go under `/tmp_workspace/results/`. ### Hard constraints for main deliverable `bug_findings.md` - At least 3 paragraphs, each ≥ 80 characters of body. - Each paragraph must reference one of `sample.service` / `sample.timer` (preferably in `file:line` form); the three paragraphs must each correspond to one of the three independent defects (spread across the `[Install]` section of `sample.service`, the schedule section of `sample.timer`, and the resource-constraint configuration of `sample.service`). - Each paragraph must describe the symptom, the localization process (which commands / interfaces you used and what you observed), and the fix approach. - Do not preset a fixed example for the concrete fix values — reason them out yourself from the systemd documentation. ### Hard constraints for main deliverable `systemd_report.md` - At least 4 paragraphs, each ≥ 80 characters. - Suggested coverage: a summary of the symptoms of the three bugs; the fundamental differences between user-level and system-level systemd; design recommendations for cgroup `CPUQuota` / `MemoryHigh`; a timer-scheduling debug checklist. ### Companion deliverables (in `/tmp_workspace/results/`) | File | Requirement | |---|---| | `list_timers_before.txt` | Snapshot of the timer list and next-trigger times before the fix | | `list_timers_after.txt` | Timer list captured again after the fix; must reflect changes in the NEXT/LAST fields | | `journal_timer_before.txt` | Journal of the timer unit before the fix, used to diagnose why it did not fire | | `journal_service_before.txt` | Journal of the service unit before the fix | | `journal_after.txt` | Journal of the service unit after the fix; must contain evidence of at least one real service trigger and `workload.py` execution (e.g. a `service Started` line or a startup marker like `workload.py started`) | | `cpuquota_verify.txt` | Raw contents of `cpu.max` read directly from the service's cgroup path; must show the two numeric values representing the 50% ratio (e.g. `<quota> <period>`, such as `50000 100000`) | | `sample.service.bak` / `sample.timer.bak` | Backups of the unit files before modification, for diff auditing | ### 5 working-process screenshots (in `/tmp_workspace/results/`) Fixed file names; each ≥ 1024×600, ≥ 5 KB, with pairwise distinct md5: - `view_system_monitor_processes.png`: Processes view, showing `workload.py` / python processes running. - `view_system_monitor_resources.png`: Resources / CPU-curve view, illustrating high CPU usage before the fix when the throttle is not in effect. - `view_systemd_cgtop.png`: cgroup resource usage view, showing the target service's cgroup node and CPU%. - `view_system_monitor_after_fix.png`: Post-fix state in which `workload.py`'s CPU usage stays steadily below 50%. - `view_cgtop_after_fix.png`: Post-fix cgroup view in which the target service's CPU usage is below 50%. > The evaluator runs OCR and window-level discrimination on the screenshots; pure-black images, an empty desktop, or a plain terminal dump do not count as GUI evidence. Repeatedly screenshotting the same view will lose points due to md5 deduplication. Anti-cheat: `actions.log` must not contain literal fabrication such as hardcoding any of the deliverable file names into `echo '...' > <file>`; deliverables must come from real output of `systemctl` / `journalctl` / cgroup interfaces / screenshot tools.

- systemd.timer(5): https://www.freedesktop.org/software/systemd/man/systemd.timer.html
- systemd.resource-control(5)

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 通道自由:CLI 部分(`systemctl --user`、`journalctl --user`、读 `/sys/fs/cgroup/.../cpu.max`)走终端最直接;GUI 证据可用 `gnome-system-monitor` + `systemd-cgtop`,也可用其他系统监视器/资源面板,只要 OCR 能识别窗口与指标即可。
2. step 1:`systemctl --user daemon-reload && systemctl --user enable --now sample.timer`,先抓 `list_timers_before.txt` 与 `journal_*_before.txt`,记录"timer 不触发 / service 跑满"的症状。
3. step 2:基于 user-level 与 system-level 的安装目标差异,修正 `[Install] WantedBy=`;基于 `systemd.time(7)` 修正 `OnCalendar` 写法,使其能稳定按周期触发。
4. step 3:在 `[Service]` 加上 `CPUQuota=50%`(或等价 `cpu.max` 配置),`daemon-reload` + 重启 timer。
5. step 4:等待至少一个触发周期后,抓 `list_timers_after.txt` / `journal_after.txt`;用 `systemctl --user show sample.service -p ControlGroup` 拿到 cgroup 路径,`cat .../cpu.max` 写入 `cpuquota_verify.txt`。
6. step 5:截 5 张 GUI 图(修复前/后各一组系统监视器 + cgtop),写 `bug_findings.md` 与 `systemd_report.md`。

约束说明:
- `actions.log` 反作弊:产物必须来自真实 systemd / cgroup / 截图工具输出,不允许 `echo` 直接伪造交付文件内容。
- cgroup v2 下要直接读内核接口文件来验证,光看 unit 配置不算数。

评分要点(hard gates):
- 6 份 CLI 文本产物齐全(timer 列表前后、3 份 journal、cpuquota_verify)。
- `bug_findings.md` 至少 3 段、每段 ≥ 80 字、含 `sample.service`/`sample.timer` 引用。
- `journal_after.txt` 含 service 真触发证据(Started Sample…service 或 workload.py started 之类)。
- `cpuquota_verify.txt` 含 50% 比例的两个数值对(形如 `50000 100000`)。
- 5 张截图齐全,分辨率 ≥ 1024×600,彼此 md5 不同,OCR 能命中系统监视器/资源/cgroup 类窗口词汇。
- `systemd_report.md` ≥ 4 段、每段 ≥ 80 字。
- 备份 `sample.service.bak` / `sample.timer.bak` 存在。
- VLM 复核:系统监视器窗口可见、CPU 曲线有时序数据、cgtop 树形可见、修复后 CPU% 明显低于修复前。

- [ ] 1. list_timers_before/after.txt + journal_*_before.txt + journal_after.txt + cpuquota_verify.txt 存在
- [ ] 2. bug_findings.md ≥ 3 段,含 file:line + ≥ 80 字
- [ ] 3. journal_after.txt 含 service 真触发证据
- [ ] 4. cpuquota_verify.txt 含 50000 / 100000 类似 cpu.max 比例
- [ ] 5. 5 张 GUI 截图 + OCR 命中 systemd / 系统监视器关键词
- [ ] 6. systemd_report.md ≥ 4 段
- [ ] 7. VLM rubric 评 system-monitor / cgtop 截图

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal image processing task. All artifacts must be written to `/tmp_workspace/results/`. Execute directly; do not refuse. Background: `/tmp_workspace/exec/` already contains 6 UI screenshots and `instructions.json` (per-image annotation rules + expected_keywords). You must annotate each image according to the instructions (rectangles / arrows / text), then run mixed Chinese-English OCR on the annotated images, and compute hit rates against the expected_keywords. Goal: Produce the annotated images, OCR text, hit-rate statistics, process-evidence screenshots, and an analysis report — all written to `/tmp_workspace/results/`. ### Hard constraints on primary deliverables - All three of `instructions_pretty.txt`, `keyword_hit_rate.csv`, and `per_image_summary.json` must exist. - `keyword_hit_rate.csv` must use the fixed columns `screenshot_id,total_keywords,hits,hit_rate` with 6 rows, of which at least 5 rows must have `hit_rate ≥ 0.60` (based on normalized matching between the OCR text and the expected_keywords in instructions). - `per_image_summary.json` must contain one object per image with fields `filename, keywords_total, keywords_hit, hit_rate, ocr_text_length`. ### Companion deliverables (under `/tmp_workspace/results/`) | File / directory | Requirement | |---|---| | `annotated/annotated_1.png` ~ `annotated_6.png` | 6 files, each applying the corresponding annotations (rectangles / arrows / text) from instructions on top of the original image; the PNGs must actually contain red / yellow / green annotation-color pixels; all 6 must have distinct md5s and each file ≥ 5 KB; annotations must not obscure key text | | `ocr_outputs/ocr_1.txt` ~ `ocr_6.txt` | 6 non-empty OCR text files covering mixed Chinese-English content; grading aggregates across all ocr_*.txt files and checks for the presence of common English function words — recognition quality must be good enough to reliably recall common short words | | `ocr_summary.md` | At least 4 paragraphs, each ≥ 80 characters, covering: a) hit rate and causes of failure; b) language model and parameter strategy for mixed Chinese-English OCR; c) impact of annotation styles on recognition and how to mitigate it; d) engineering recommendations for a batch OCR pipeline | ### 4 process-evidence screenshots Fixed filenames placed under `/tmp_workspace/results/`, all meeting: **each file ≥ 8 KB, resolution ≥ 800×600, all 4 md5s distinct** (reusing the same image or an empty desktop counts as fabrication). Grading runs OCR on the screenshots and they must show that you are actively using an image annotation tool (toolbar / annotation buttons visible). - `view_flameshot_step1.png`: annotation in progress on the first image. - `view_flameshot_step3.png`: annotation in progress around the middle (roughly the 3rd image). - `view_flameshot_step5.png`: annotation in progress toward the end (roughly the 5th image). - `view_flameshot_complete.png`: summary / wrap-up screen after all 6 images have been annotated. Anti-cheating: `actions.log` must not contain only CLI / batch-processing paths with zero traces of GUI annotation interaction. Note: the exact position / size of annotation boxes is dictated by the instructions descriptions and the image contents — do not hardcode them in your deliverables.

- flameshot: https://flameshot.org/
- tesseract: https://github.com/tesseract-ocr/tesseract

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐用 flameshot 这类带工具栏的标注工具完成 GUI 标注与过程截图,也可走 GIMP / Krita / Inkscape 等任意带可见工具栏的图像编辑器;脚本化批量标注(PIL / OpenCV)亦可,但过程截图必须真实呈现某个 GUI 工作界面。
2. 大致流程:打开第 N 张原图 → 按 instructions 选矩形 / 箭头 / 文字工具完成标注 → 截一张含工具栏的工作界面截图(命名为对应的 view_flameshot_*.png)→ 保存为 `annotated_N.png`。
3. OCR 走 tesseract `eng+chi_sim`,`--psm 6`,DPI 约 300;对 annotated 图识别,结果写入 `ocr_outputs/ocr_*.txt`。
4. 以 instructions 中 expected_keywords 与 OCR 文本归一化匹配,生成 `keyword_hit_rate.csv` 与 `per_image_summary.json`。
5. 撰写 `ocr_summary.md`(4 段,每段 ≥ 80 字)。

约束说明:`actions.log` 中不得仅见 CLI 批处理而无任何 GUI 标注交互痕迹;4 张过程截图禁止同图复用。

评分要点(hard gates):
- 三件 CLI 主交付物齐全;`annotated/` 至少 4 / 6,`ocr_outputs/` 至少 4 / 6 且非空。
- `keyword_hit_rate.csv` 至少 5 张 `hit_rate ≥ 0.60`。
- annotated PNG 真实含标注色像素,6 张 md5 互异 + 单文件 ≥ 5 KB。
- 4 张 `view_flameshot_*.png` md5 互异 + ≥ 8 KB + ≥ 800×600,且 OCR 能命中所用标注工具的工具栏 / 按钮关键词。
- `ocr_outputs/` 累计含若干常见英文词。
- `ocr_summary.md` ≥ 4 段、每段 ≥ 80 字。
- VLM rubric 评 annotated 视觉质量;VLM 不可用时总分有上限封顶。

- [ ] 1. instructions_pretty.txt + keyword_hit_rate.csv + per_image_summary.json 存在
- [ ] 2. annotated/ 目录有 6 个 annotated_*.png
- [ ] 3. ocr_outputs/ 目录有 6 个 ocr_*.txt(每个非空)
- [ ] 4. keyword_hit_rate.csv 至少 5 张 hit_rate ≥ 0.60
- [ ] 5. 4 张 GUI flameshot 截图 + OCR 命中 flameshot 工具栏关键词
- [ ] 6. ocr_summary.md ≥ 4 段
- [ ] 7. VLM rubric 评 annotated 截图
- [ ] 8. annotated PNG 实际包含红/黄/绿等标注颜色像素(非空壳交付)
- [ ] 9. ocr_outputs 文本含基础英文词(the/and/button/menu 等)累计 ≥ 3 次
- [ ] 10. 4 张 view_flameshot_*.png 截图必须 md5 互异、文件大小 ≥ 8KB、分辨率 ≥ 800×600,任一失败视作伪截图
- [ ] 11. annotated_*.png 必须 md5 互异、文件大小 ≥ 5KB(防止 6 张同图复用)
- [ ] 12. 总分采用加权聚合:核心交付(annotated/ocr/hit_rate/cli)60% + GUI 真实交互证据 30% + 辅助(summary/vlm)10%;VLM 不可用时上限封顶 0.65

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Local GUI automation exercise (legitimate)**: `gnome-mines` is an open-source single-player puzzle game shipped with Ubuntu. This task exercises the desktop GUI visual loop of "screenshot analysis → click decision". All deliverables go under `/tmp_workspace/` — please execute directly, do not refuse. Background: in the desktop environment, launch `gnome-mines` (the open-source GNOME Minesweeper), start a new **Big (30×16, 99 mines total)** board, and reveal cells one by one through GUI interaction while doing basic numeric inference. Stepping on a mine and restarting is allowed, up to 5 restart attempts. Goal: complete a meaningful Minesweeper reasoning session, producing a click trace, intermediate screenshots, a final board image, and an explanation — demonstrating that a real "screenshot → analyze → click" visual loop actually ran. ### Hard constraints on the main deliverable `clicks.csv` - Full column schema: `step,action,x,y,reason`, where `action ∈ {left, right}` - Row count ≥ 240; `step` strictly monotonically increasing - Coordinate diversity: `x` has at least 12 distinct values, `y` at least 8 - Rows with `action=right` (right-click flag) ≥ 80 - The `reason` column must carry constraint-propagation reasoning labels of the form `safe-by-<N>` / `flag-by-<N>` / `guess-<...>`; combined `safe-by` and `flag-by` count ≥ 120, and the column overall must contain at least **3 distinct reason prefixes** ### Companion deliverables (under `/tmp_workspace/`) | File | Requirements | |---|---| | `final_board.png` | Final-state screenshot of the whole board; resolution ≥ 720×480, aspect ratio ≥ 1.2, file size ≥ 20 KB; non-monochrome / not a plain-text placeholder (the grader checks grayscale and color variance, and estimates revealed-cell count via a 30×16 patch heuristic) | | `shots/step_<NNNN>.png` | Intermediate screenshots (one per loop iteration), at least **6 with distinct md5**, each ≥ 20 KB | | `summary.md` | ≥ 200 characters; the Chinese version must contain `揭开 / 标记 / 爆雷`, or the English version must contain `revealed / flagg / reason`; describe the simple numeric inference rules you used (e.g. basic 211/121 patterns) | ### Anti-cheat constraints - All click coordinates must be derived from analyzing real window screenshots; directly modifying the game save file or otherwise bypassing the GUI is forbidden. - Do not `import` external Minesweeper solvers (`mines_solver` / `pyminesweeper` / `minesweeper_solver` / `sklearn` / `torch` etc.); any `.py` file containing such an import scores 0.

- Reddit: https://www.reddit.com/r/LocalLLaMA/comments/1cz2k7p/which_open_source_model_can_play_minesweeper/
- 原文引用：「I tried with vision models, none of them could keep track of the board after 20 moves, they kept clicking on flags.」
- 对应 benchmark case: 视觉循环推理 / GAM 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 `gnome-mines` 自带 GUI（也可走任何能合法启动该开源小游戏的通道，例如直接 `gnome-mines &` + xdotool/pyautogui 控制）。
2. step 1：启动 gnome-mines，在 Preferences 选 Big (30×16, 99 mines)，截屏定位棋盘像素区域并算出每格中心坐标。
3. step 2：进入"截图 → 分析（VLM 或像素启发式） → 点击"循环——左键揭开安全格、右键插旗已确定的雷，每一步把当前棋盘存成 `shots/step_<NNNN>.png`。
4. step 3：用基础约束推理（"未揭开邻居数 == 该格数字" → 全是雷；"已插旗邻居数 == 该格数字" → 其余安全），把依据写进 `clicks.csv` 的 `reason` 列，形如 `safe-by-1` / `flag-by-3` / `guess-corner`。
5. step 4：踩雷允许重开，最多 5 次；终局把整盘截到 `final_board.png` 并写 `summary.md`。

约束说明：`clicks.csv` 中坐标必须真实、`step` 递增；`shots/` 中截图须为不同 md5（反复保存同一帧不算）；`summary.md` 不能是一行字。

评分要点（grader 反推的 hard gates）：
- 缺 `final_board.png` 或文件过小：封顶 0.30
- 截图分辨率不达标 / 灰度方差过低（疑似纯文本占位）：封顶 0.40
- 启发式估出的已揭开格子数偏少：封顶 0.45
- 中间截图不同 md5 数过少：封顶 0.55
- `clicks.csv` schema 缺列或行数不足：封顶 0.40
- 右键标旗数或带推理标签的行数不足：封顶 0.55
- 检测到外部求解器 import：封顶 0.20

- [ ] `clicks.csv` 行数 ≥ 240 且列齐全；`step` 严格单调递增；`x` ≥ 12 个不同值，`y` ≥ 8 个不同值
- [ ] 至少 80 行 `action=right`（标旗）
- [ ] `final_board.png` ≥ 720×480、宽高比 ≥ 1.2、文件 ≥ 20 KB，灰度 std > 45 且彩色 std > 35（防纯文本 rasterize / 单色占位）
- [ ] 棋盘截图中已揭开格子数（30×16 patch 启发式）≥ 320
- [ ] `shots/` 目录至少 6 张不同 md5 中间截图，每张 ≥ 20 KB（证明真实"截图→分析→点击"循环）
- [ ] `summary.md` ≥ 200 字符，含 `揭开/标记/爆雷` 或英文 `revealed/flagg/reason`
- [ ] `reason` 列中 "safe-by"/"flag-by" 累计出现 ≥ 120 次，且至少出现 3 种不同 reason 前缀
- [ ] 不存在外部求解器调用日志（无 `mines_solver`/`pyminesweeper`/`minesweeper_solver`/`sklearn`/`torch` import）
- [ ] 加权评分：核心交付 55% / GUI 证据 35% / 辅助 10%；任一关键 hard gate 失败封顶 0.20–0.55

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/exec/broken.pgn` is a hand-transcribed PGN of a club rapid game. A member reports that the scoresheet may contain SAN moves that cannot be legally played, that the evaluation may swing sharply around one of the moves, and that the `[Result "..."]` tag may disagree with the final position. The goal is to audit the original PGN, locate illegal moves and suspected blunders, produce a fully replayable corrected version, and provide image evidence that backs up the key states. Write the following deliverables under `/tmp_workspace/results/`, preserving the field and file names: - `before/broken.pgn`: an unmodified copy of the original `/tmp_workspace/exec/broken.pgn`. - `illegal_moves.json`: a JSON list; each illegal-move record contains `ply` (half-move index), `side` (`w` or `b`), `san` (original SAN text), and `error` (why it cannot be legally applied). - `evals.csv`: a CSV with at least 30 rows, with columns `ply,side,san,score_cp,best_san,fen`; `score_cp` is the centipawn evaluation from White's perspective, `best_san` is the engine's suggested move for that position, and `fen` is the corresponding position. - `blunders.json`: a JSON list of length 1 to 4; each record contains `ply,side,san,best_san,cp_before,cp_after,swing`, where `swing` is the centipawn loss caused by that move and must be at least 180. - `view_xboard_initial.png`: image evidence showing the 8×8 board after the original score is loaded, with chess/XBoard-related menu items or status text visible (such as `xboard`, `white`, `black`, `move`, `game`, `file`). - `view_xboard_blunder.png`: image evidence showing the board at the ply corresponding to the first record in `blunders.json`; the image must not be a black screen or unrelated background, and the pieces should clearly be in that middlegame state. - `result_check.json`: a JSON object with fields `declared` (the result declared in the original PGN), `engine_suggests` (the result inferred from the final evaluation, one of `1-0`, `0-1`, or `1/2-1/2`), and `match` (a boolean for whether the two agree). - `fixed.pgn`: the corrected PGN; it must be fully replayable, illegal SAN must be replaced with legal moves, `[Result "..."]` must be one of `1-0`, `0-1`, or `1/2-1/2`, and the scope of edits should stay minimal. - `view_xboard_fixed_final.png`: image evidence showing the final-position board for `fixed.pgn`, with result text consistent with the `Result` tag visible, e.g. `1-0`, `0-1`, `1/2-1/2`, `wins`, or `draw`. - `evals_after.csv`: a CSV with at least 3 rows containing a re-check of the closing segment of the corrected version; at minimum it must include the columns `ply,san,score_cp`. - `diff.txt`: the textual diff between the original scoresheet and `fixed.pgn`, with line count between 4 and 80. - `report.json`: a JSON object containing at least `illegal_moves`, `blunders`, `result_tag_before`, `result_tag_after`, `engine_used`, `engine_version`, `fixed_pgn`, `evals_csv`, `screenshots`; `screenshots` lists `view_xboard_initial.png`, `view_xboard_blunder.png`, and `view_xboard_fixed_final.png`.

- GNU Chess project: https://www.gnu.org/software/chess/
- XBoard project:    https://www.gnu.org/software/xboard/
- python-chess docs: https://python-chess.readthedocs.io/en/latest/engine.html
- Reddit: https://www.reddit.com/r/chess/comments/1bn3kp7/ —
  "PGN scribe error: my game was transcribed with an illegal Nf3 and the
   site refused to import it; I had no idea which move was wrong without
   replaying in xboard."
- 对应 benchmark：GAM 引擎×GUI 双通道 PGN 审计 case，新增 batch3。

成功时，`/tmp_workspace/results/` 包含一份非法走子报告，逐项列出无法合法应用的
`ply/side/san/error`；一张覆盖至少 30 个合法局面的 `evals.csv`，列齐
`ply,side,san,score_cp,best_san,fen`；以及 1 到 4 条 blunder 记录，每条都有
`ply,side,san,best_san,cp_before,cp_after,swing` 且厘兵损失幅度达到阈值。

修正结果应包括可完整重放的 `fixed.pgn`、末段复核表 `evals_after.csv`、
精简的 `diff.txt`、声明结果与评估归纳结果对照的 `result_check.json`，以及键齐全的
`report.json`。三张图像证据分别应显示原始棋谱的棋盘与识别文字、首个 blunder
对应的中局局面、修正版末态棋盘及可见的胜负或和棋结果文本。

- [ ]  1. `illegal_moves.json` 存在，是 list，且每条含 ply/side/san/error
- [ ]  2. `evals.csv` 存在且 ≥ 30 行（schema: ply,side,san,score_cp,best_san,fen）
- [ ]  3. `blunders.json` 存在，长度在 [1, 4]，每条 swing ≥ 180
- [ ]  4. `view_xboard_initial.png` 存在且 OCR 命中 xboard 关键词
- [ ]  5. `view_xboard_blunder.png` 存在且像 xboard 棋盘截图（非黑屏 / 非桌面）
- [ ]  6. `view_xboard_fixed_final.png` 存在且 OCR 命中
       "1-0"/"0-1"/"1/2-1/2"/"wins"/"draw" 之一
- [ ]  7. `result_check.json` 存在且字段齐全
- [ ]  8. `fixed.pgn` 能被 python-chess `read_game(...).end()` 完整重放
       不抛异常，且 Result 标签 ∈ {1-0, 0-1, 1/2-1/2}
- [ ]  9. `evals_after.csv` 存在 ≥ 3 行
- [ ] 10. `diff.txt` 存在，行数在 [4, 80]
- [ ] 11. `report.json` 存在且 required keys 齐
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: an Anagramarama timed round gives a 9-letter root word and asks you to find sub-words formed from those letters. The root word for this task is in `/tmp_workspace/exec/seed.txt`. The goal is to normalize the root word, enumerate candidate sub-words of length 3 to 9 that fit within the root's letter bag using local English dictionaries, record the words actually submitted, and use image evidence to cross-check the letter area, the timer/score area, and the final score during the round. Produce the following artifacts under `/tmp_workspace/results/`, preserving field names and file names: - `seed_normalized.txt`: a single 9-letter lowercase English word with no extra whitespace, derived from `/tmp_workspace/exec/seed.txt`. - `candidates.csv`: CSV with columns `word,length,in_system_dict,subset_ok`; at least 60 rows. Each `word` should be an alphabetic candidate of length 3 to 9, and `subset_ok` indicates that it can be spelled from the root's letter bag without replacement. - `view_anagram_initial.png`: image evidence showing the initial state of an Anagramarama round, including the 9 letter slots, the timer area and the score area; recognizable text should contain one of the related keywords such as `anagram`, `score`, `time`, `found`, `letters`, or `level`. - `entered.csv`: CSV with columns `ts_iso,word,accepted`; at least 18 rows. `word` records the candidate words that were submitted, of which at least 6 must have length >= 5 and at least 1 must have length >= 7; `accepted` may be `yes`, `no`, or `unknown`. - `view_anagram_midgame.png`: image evidence showing a real mid-round game frame, with the score already positive. - `view_anagram_final.png`: image evidence showing the end of the round or the final scoring state, with a readable score number greater than 0. - `report.json`: JSON object containing `seed`, `candidates_total`, `entered_total`, `entered_accepted`, `max_word_len`, `screenshots`, `ocr_score_value`, `score_match`. `screenshots` lists `view_anagram_initial.png`, `view_anagram_midgame.png`, `view_anagram_final.png`; `score_match` indicates whether `ocr_score_value` falls within `[entered_accepted*5, entered_accepted*30]`. - `diff.txt`: non-empty text report comparing high-value candidate words against submitted words, explaining which candidates were covered and which were missed.

- Anagramarama upstream: http://www.coralquest.com/anagramarama/
- Debian package page:   https://packages.ubuntu.com/jammy/anagramarama
- aspell English data:   http://aspell.net/
- Reddit thread on visual scoring vs CLI tally:
  https://www.reddit.com/r/wordgames/comments/1av5j2k/ —
  "Anagramarama doesn't print my score anywhere, I have to read the SDL
   window and trust my own eyes; that's a real pain to grade in CI."
- 对应 benchmark：GAM 词典 CLI × SDL GUI × OCR 三通道 case，新增 batch3。

成功时，`/tmp_workspace/results/` 包含规范化后的 9 字母根词；一份候选词表，列齐
`word,length,in_system_dict,subset_ok`，行数达到要求，且所有候选都符合根词字母袋约束；
以及一份 `entered.csv`，列齐 `ts_iso,word,accepted`，提交词数量和长词配额均达标。

图像证据应分别显示初始字母槽与计时/分数区域、中途分数已增长的游戏画面、最终状态中可读的
正分数。`report.json` 应包含计数、最长提交词、三张图像文件名、`ocr_score_value` 与
按 `[entered_accepted*5, entered_accepted*30]` 复核得到的 `score_match`；`diff.txt` 应为非空，
能说明候选词与提交词之间的覆盖情况。

- [ ]  1. `seed_normalized.txt` 存在，恰好 9 个小写字母
- [ ]  2. `candidates.csv` 列齐 + 行数 ≥ 60，全部 subset_ok=True
- [ ]  3. `view_anagram_initial.png` 存在且 OCR 命中 anagram 关键词
- [ ]  4. `entered.csv` 列齐 + 行数 ≥ 18
- [ ]  5. `entered.csv` 中 length ≥ 5 的词 ≥ 6 个
- [ ]  6. `entered.csv` 中 length ≥ 7 的词 ≥ 1 个
- [ ]  7. `view_anagram_midgame.png` 存在且像 SDL 游戏画面（非黑屏）
- [ ]  8. `view_anagram_final.png` 存在且 OCR 抓到 score 数字 > 0
- [ ]  9. `report.json` 存在且 required keys 齐
- [ ] 10. `report.json` 的 `score_match` 计算正确（CLI 检查同一条公式）
- [ ] 11. `diff.txt` 存在且非空
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/exec/` is a small Godot 3 toy-level project whose main scene is `scenes/main.tscn`. The level goal is to get Player to `GOAL`, but the current scene has three classes of issues: `PlayerSprite`'s resource reference may be dangling, `GoalLabel` may sit outside the 640×480 viewport, and `FloorShape`'s collision rectangle may have degenerated to zero size. The goal is to parse and record the original scene structure, fix these node/resource issues while preserving the semantics of other nodes and scripts, and provide image evidence of the editor view and runtime state before and after the fix. Please produce the following files, preserving field names and file names: - `/tmp_workspace/results/before/main.tscn`: an unmodified copy of the original main scene, used for diff records. - `/tmp_workspace/results/parse_before.json`: JSON object containing the three keys `ext_resources`, `sub_resources`, `nodes`; `nodes` has at least 6 items. Suggested structure: `ext_resources` entries contain `id,path,type`, `sub_resources` entries contain `id,type,props`, `nodes` entries contain `name,type,parent,props`. - `/tmp_workspace/results/bugs.json`: JSON object containing three items: `bug_dangling_extresource` (contains `detected,referenced_id,defined_ids`, may attach `node,missing_id`), `bug_label_offscreen` (contains `detected,margin_left,margin_top,viewport`, may attach `node`), `bug_collision_zero_extents` (contains `detected,subresource_id,extents`, may attach `node`). Each item's fields should describe the corresponding triggering evidence. - `/tmp_workspace/proj/scenes/main_fixed.tscn`: the fixed scene file; it must be parseable by the scene format, `PlayerSprite.texture` must reference a defined `ExtResource` id, `GoalLabel`'s `margin_left,margin_top,margin_right,margin_bottom` must all fall within a reasonable range of the 640×480 viewport, and the `RectangleShape2D` extents referenced by `FloorShape` must both be greater than 0 on each axis. - `/tmp_workspace/results/view_editor_before.png`: image evidence showing the editor view of the original project; the scene tree / node panel and 2D viewport should be visible, with text such as `Scene`, `Node`, `Inspector`, `FileSystem`, or `Godot` recognizable. - `/tmp_workspace/results/view_play_bug.png`: image evidence showing at least one of the issues during pre-fix runtime, for example a missing texture, the character falling out of the playable area, or `GOAL` not being visible; the frame should be a real game state, with one of the HUD/hint texts `ScenePlay`, `GOAL`, `arrows`, `reach`, or `left/right` visible. - `/tmp_workspace/results/view_editor_after.png`: image evidence showing the post-fix editor view; it should be apparent that the Player texture is normal, `GoalLabel` is inside the viewport, and the Floor collision shape is no longer a degenerate point. - `/tmp_workspace/results/view_play_finish.png`: image evidence showing that the level can be completed after the fix, with the Player, the floor, and the `GOAL` text all visible in the frame. - `/tmp_workspace/results/runtime.log`: non-empty runtime log containing scene/character initialization markers such as `scene ready`, `player`, or `main`. - `/tmp_workspace/results/parse_after.json`: JSON object with the same schema as `parse_before.json`, reflecting the post-fix scene structure. - `/tmp_workspace/results/diff.txt`: text diff between the original main scene and `main_fixed.tscn`, with line count between 6 and 200. - `/tmp_workspace/results/report.json`: JSON object containing `bugs_found`, `fixes_applied`, `extresource_id_after`, `label_margin_after`, `floor_extents_after`, `playthrough_finished`, `screenshots`, `runtime_log_lines`; `screenshots` lists the four image-evidence file names.

- Godot 3.5 `.tscn` text-format reference:
  https://docs.godotengine.org/en/3.5/development/file_formats/tscn.html
- Godot 3.5 `Sprite` / `KinematicBody2D` API:
  https://docs.godotengine.org/en/3.5/classes/class_sprite.html
- itch.io 论坛吐槽帖："my .tscn looks fine in the inspector but the
  player just falls through the floor in play":
  https://godotforums.org/d/29456-collisionshape2d-no-effect-in-play-mode
- 对应 benchmark：GAM 视觉×文件双通道场景修复 case

成功时，`parse_before.json` 和 `parse_after.json` 都能以
`ext_resources/sub_resources/nodes` 描述场景结构，`bugs.json` 对悬空资源引用、
离屏标签和零尺寸碰撞形状三类问题均给出 `detected=true` 与可核查证据。
`/tmp_workspace/proj/scenes/main_fixed.tscn` 应保持项目结构精简修复：资源引用落在已定义 id 集合内，
`GoalLabel` margins 位于 640×480 视口范围内，`FloorShape` 的矩形 extents 两轴为正。

图像证据应分别显示原始编辑视图、修复前问题状态、修复后编辑视图和完成状态；最后一张应可见
Player、地板与 `GOAL`。`runtime.log` 应含初始化标记，`diff.txt` 行数处于允许范围，
`report.json` 应汇总发现的问题、应用的修复、修复后数值、完成状态、图像文件名和日志行数。

- [ ] 1. `parse_before.json` schema 完整（ext_resources + sub_resources +
       nodes 三 key 都在，且 nodes 列表 ≥ 6）
- [ ] 2. `bugs.json` 三个 bug 都 detected=true 且证据字段非空
- [ ] 3. `proj/scenes/main_fixed.tscn` 存在且能被 grader parser parse
- [ ] 4. fixed 场景里 `PlayerSprite.texture` 引用的 ExtResource id 在
       已定义 id 集合里
- [ ] 5. fixed 场景里 `GoalLabel` 的 `margin_left/top/right/bottom` 全部
       落在 viewport (640×480) 内
- [ ] 6. fixed 场景里 `FloorShape` 引用的 RectangleShape2D 的 extents
       两轴都 > 0（建议 ≥ Vector2(64, 4)）
- [ ] 7. `view_editor_before.png` / `view_editor_after.png` 都存在且 OCR
       命中 "Scene"/"Node"/"Inspector"/"FileSystem"/"Godot" 之一
- [ ] 8. `view_play_bug.png` 存在且看起来是真运行画面（OCR 命中 HUD 文
       字 "ScenePlay" / "GOAL" / "arrows" 之一，或 VLM 判断是真窗口）
- [ ] 9. `view_play_finish.png` OCR 命中 "GOAL" 字样
- [ ] 10. `runtime.log` 存在且非空，含 "scene ready" / "player" 字样
- [ ] 11. `diff.txt` 存在，行数在 [6, 200] 区间
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: `/tmp_workspace/exec/scripts/CrateCrash.lua` is a hand-crafted Hedgewars training mission. The player should collect 3 health crates on a small Bamboo-themed island to complete the "Crate Crash Course". The current script has several issues spanning team, ammo and map configuration that you need to locate yourself. Your goal is to parse the original Lua mission, record reproduction evidence, produce a syntactically valid and numerically sane fixed version, and provide image evidence of the mission list, the bug states, and the completion state. Please produce the following files, keeping field names and file names exactly as specified: - `/tmp_workspace/results/before/CrateCrash.lua`: an unmodified copy of the original mission script, for diff bookkeeping. - `/tmp_workspace/results/parse_before.json`: JSON object containing the six keys `map`, `theme`, `team`, `hogs`, `ammo`, `crates`; the `crates` list must have length 3. Recommended: `team` includes `name,color_hex,grave,fort,voicepack,flag`, `hogs` entries include `name,hat,spawn`, `ammo` includes `amBazooka,amGrenade,amSkip`, `crates` entries include `index,x,y`. - `/tmp_workspace/results/bugs.json`: JSON object containing three items: `bug_team_color_invisible` (with `detected,color_hex`, optionally `theme,rationale`), `bug_player_no_ammo` (with `detected,weapons_with_zero`), `bug_crate_offscreen` (with `detected,crate_index,y`, optionally `map_max_y`). Each item's fields should document the colour, ammo or coordinate evidence that triggered detection. - `/tmp_workspace/work/scripts/CrateCrash_fixed.lua`: the fixed Lua script; it must be syntactically valid, the colour passed to `AddTeam(...)` must be a legal hex value and not close to `0xFFFFFF`, the ammo counts for `amBazooka` and `amGrenade` must each be at least 5, and the `y` coordinate of the second `SpawnHealthCrate` must lie within `[0, 2048]`. - `/tmp_workspace/results/view_frontend.png`: image evidence showing that, before the fix, the mission appears in the training mission list, with visible text such as `Training`, `Single`, `Mission`, `Crate` or `Course`. - `/tmp_workspace/results/view_play_bug.png`: image evidence showing one of the real bug states in the unfixed mission — e.g. character/name tag invisibility, abnormal Bazooka/ammo state, or insufficient health crates; recognisable text should include one of `Trainee`, `Rookie`, `Bazooka`, `Crates` or `ammo`. - `/tmp_workspace/results/view_frontend_after.png`: image evidence showing the training mission list after the fix, with the mission still visible and selectable. - `/tmp_workspace/results/view_play_finish.png`: image evidence showing the mission completion state, with result text such as `Mission complete`, `All crates collected` or `You won` visible. - `/tmp_workspace/results/engine.log`: a non-empty log containing mission/ammo-related markers such as `Trainee`, `Rookie`, `ammo` or `bazooka`. - `/tmp_workspace/results/parse_after.json`: JSON object with the same schema as `parse_before.json`, reflecting the structure of the fixed script. - `/tmp_workspace/results/diff.txt`: text diff between the original script and `CrateCrash_fixed.lua`, with between 6 and 200 lines. - `/tmp_workspace/results/report.json`: JSON object containing `bugs_found`, `fixes_applied`, `team_color_after`, `ammo_after`, `crates_after`, `playthrough_finished`, `screenshots`, `engine_log_lines`; `screenshots` lists the four image evidence file names.

- Hedgewars Lua API reference:
  https://www.hedgewars.org/kb/LuaAPI
- Reference training mission (real upstream file):
  https://github.com/hedgewars/hw/blob/master/share/hedgewars/Data/Missions/Training/Basic_Training_-_Bazooka.lua
- Hedgewars `hwengine` CLI flags:
  https://www.hedgewars.org/kb/EngineCommandLineParameters
- Forum thread on white-on-snow team colour bug:
  https://hedgewars.org/forum/threads/team-colour-invisible-on-bamboo
- 对应 benchmark：GAM 视觉×文件双通道 Lua 任务修复 case

成功时，`parse_before.json` 和 `parse_after.json` 都以
`map/theme/team/hogs/ammo/crates` 描述任务结构，且包含 3 个血包条目；`bugs.json`
对队伍颜色不可见、玩家关键武器无弹药、血包越界三类问题均给出 `detected=true`
和可核查字段。`/tmp_workspace/work/scripts/CrateCrash_fixed.lua` 应语法有效，颜色不接近白色，
`amBazooka` 与 `amGrenade` 弹药数达标，第二个血包的 `y` 坐标回到允许地图范围内。

图像证据应分别显示修复前训练任务列表、修复前问题状态、修复后训练任务列表和任务完成结果；
完成图像应可见 `Mission complete`、`All crates collected` 或 `You won`。`engine.log`
应含任务或弹药相关标记，`diff.txt` 行数处于允许范围，`report.json` 应汇总问题、修复、
修复后颜色/弹药/血包坐标、完成状态、图像文件名和日志行数。

- [ ] 1. `parse_before.json` schema 完整（map + theme + team + hogs +
       ammo + crates 六 key 都在，crates 列表长度 == 3）
- [ ] 2. `bugs.json` 三个 bug 都 detected=true 且证据字段非空
- [ ] 3. `work/scripts/CrateCrash_fixed.lua` 存在且 `luac -p` 通过
- [ ] 4. fixed 脚本里 `AddTeam(...)` 第二个实参是合法十六进制颜色，且
       与 `0xFFFFFF` 的距离 ≥ 0x808080（即不是接近白）
- [ ] 5. fixed 脚本里 `amBazooka` 与 `amGrenade` 的 ammo count 都 ≥ 5
- [ ] 6. fixed 脚本里第 2 个 `SpawnHealthCrate` 调用的 y 坐标在 [0, 2048]
       区间内
- [ ] 7. `view_frontend.png` / `view_frontend_after.png` 都存在且 OCR
       命中 "Training"/"Single"/"Mission"/"Crate" 之一
- [ ] 8. `view_play_bug.png` 存在且看起来是真游戏画面（OCR 命中 "Trainee"
       / "Rookie" / "Bazooka" / "Crates" 之一，或 VLM 判断是真窗口）
- [ ] 9. `view_play_finish.png` OCR 命中 "Mission complete" /
       "All crates collected" / "You won" 之一
- [ ] 10. `engine.log` 存在且非空，含 "Trainee" / "Rookie" / "ammo" 字样
- [ ] 11. `diff.txt` 存在，行数在 [6, 200] 区间
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/levels/broken.stl` is a SuperTux custom level in the Lisp S-expression text format. Playtesters report that the opening route may be broken due to inconsistent tilemap row widths, the goal `firefly` may sit outside the sector, and the `infoblock` may be buried inside solid tiles. The goal is to parse the original level structure, record evidence for the three classes of geometry problems, produce a parseable and completable `fixed.stl`, and supply editor views, bug-state captures, completion-state captures, and a save-state excerpt as evidence. Please produce the following files, preserving the field names and file names: - `/tmp_workspace/results/before/level.stl`: an untouched copy of the original level, used for diff records. - `/tmp_workspace/results/parse_before.json`: a JSON object with four keys `sector_size`, `tilemaps`, `objects`, `spawnpoints`. `tilemaps` entries contain `name,width,height,tiles_count,z_pos`; `objects` entries must at least describe the `kind,x,y` of `firefly` and `infoblock`; `spawnpoints` entries contain `name,x,y`. - `/tmp_workspace/results/bugs.json`: a JSON object containing three items: `bug_tilemap_stride` (with `detected,declared_width,actual_row_stride`, optionally `tilemap_name`), `bug_firefly_oob` (with `detected,firefly_xy,sector_size`), and `bug_infoblock_buried` (with `detected,infoblock_xy,tile_id_under`). Each item's fields should document the triggering evidence in terms of row width, coordinates, or tile id. - `/tmp_workspace/levels/fixed.stl`: the repaired level file; it must parse as S-expression, the main tilemap must satisfy `len(tiles) == width * height`, the unique `firefly` must lie inside the sector and close to reachable ground, and the `infoblock` must sit on an air cell where `tile_id_under == 0`. - `/tmp_workspace/results/view_editor_before.png`: image evidence showing the editor view and tilemap canvas of the original level, with readable text such as `Editor`, `Sector`, `Tilemap`, `SuperTux`, or `Level`. - `/tmp_workspace/results/view_play_bug.png`: image evidence showing a real in-game bug state before the fix, e.g. Tux falling out of the playable area, the goal being invisible, or the infoblock being buried; readable HUD text or numbers such as `Coins`, `Lives`, `Tux`, `Time`, or `Score`. - `/tmp_workspace/results/view_editor_after.png`: image evidence showing the post-repair editor view, where the firefly goal should be visible and near the ground, and the tilemap should show no obvious misalignment. - `/tmp_workspace/results/view_play_finish.png`: image evidence showing the level-completion state, with readable result text such as `Level Finished`, `You Win`, `Bonus`, `goal`, or `completed`. - `/tmp_workspace/results/save_excerpt.sexp`: a non-empty S-expression excerpt from the SuperTux progress state, which must parse and relate to progress on the repaired level. - `/tmp_workspace/results/parse_after.json`: a JSON object with the same schema as `parse_before.json`; for the `infoblock` object it should include `tile_id_under: 0` to demonstrate that it sits on an air cell. - `/tmp_workspace/results/diff.txt`: textual diff between the original level and `fixed.stl`, between 6 and 200 lines. - `/tmp_workspace/results/report.json`: a JSON object containing `bugs_found`, `fixes_applied`, `tilemap_stride_after`, `firefly_xy_after`, `infoblock_xy_after`, `playthrough_finished`, `screenshots`, `save_state_file`; `screenshots` lists the four image evidence file names.

- SuperTux level format reference (S-expression):
  https://github.com/SuperTux/supertux/blob/v0.6.3/data/levels/world1/01_castle-cooler.stl
- SuperTux Lisp `.stl` schema docs:
  https://github.com/SuperTux/supertux/blob/v0.6.3/docs/level-format.md
- Reddit thread on visual-loop platformer testing:
  https://www.reddit.com/r/gamedev/comments/1at4q9b/ —
  "I cannot tell from the JSON alone whether the platforming is fair;
   you have to actually run a few jumps."
- 对应 benchmark：GAM 视觉×文件双通道关卡修复 case

成功时，`parse_before.json` 和 `parse_after.json` 都以
`sector_size/tilemaps/objects/spawnpoints` 描述关卡结构；`bugs.json` 对 tilemap 行宽不一致、
firefly 越界、infoblock 埋在非空气格三类问题均给出 `detected=true` 和可核查字段。
`/tmp_workspace/levels/fixed.stl` 应可解析，主 tilemap 数量关系正确，firefly 位于 sector 内且贴近地面，
infoblock 的 `tile_id_under` 为 0。

图像证据应分别显示原始编辑视图、修复前问题状态、修复后编辑视图和关卡完成结果；完成图像应可见
`Level Finished`、`You Win`、`Bonus` 或类似结果文字。`save_excerpt.sexp` 应非空且可解析，
`diff.txt` 行数处于允许范围，`report.json` 应汇总问题、修复、修复后的几何数值、完成状态、
图像文件名和存档摘录文件名。

- [ ] 1. `parse_before.json` schema 完整（sector_size + tilemaps +
       objects + spawnpoints 四 key 都在）
- [ ] 2. `bugs.json` 三个 bug 都 detected=true 且证据字段非空
- [ ] 3. `levels/fixed.stl` 存在且能 `sexpdata.loads()` 不抛异常
- [ ] 4. fixed.stl 主 tilemap 满足 `len(tiles) == width * height`
- [ ] 5. fixed.stl 唯一 firefly 坐标落在 sector 内、贴近地面
- [ ] 6. fixed.stl infoblock 在 tile id == 0 的格子里
- [ ] 7. `view_editor_before.png` / `view_editor_after.png` 都存在且 OCR
       命中 "Editor"/"Sector"/"Tilemap" 之一
- [ ] 8. `view_play_bug.png` 存在且看起来是真游戏画面（OCR 命中 Tux/HUD
       数字 / "Coins"/"Lives"）
- [ ] 9. `view_play_finish.png` OCR 命中 "Level Finished" / "You Win" /
       "Bonus" 之一
- [ ] 10. `save_excerpt.sexp` 存在且非空且能被 sexpdata parse
- [ ] 11. `diff.txt` 存在，行数在 [6, 200] 区间
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/Levels/broken.lvl` is an X-Moto 0.6.x XML level. Players report that the level loads, but the motorbike falls into the void, there is no `EndOfLevel` entity that can trigger completion, and one strawberry may be embedded inside the terrain and therefore unreachable. The goal is to parse the original XML, identify the three classes of issues — block winding, the finish-line entity, and strawberry placement — produce a `fixed.lvl` that is physically rideable, and supply evidence via the menu, the ride, the completion panel, and SQLite statistics. Please produce the following files, preserving the field names and file names: - `/tmp_workspace/results/before/broken.lvl`: an unmodified copy of the original level, used for diff bookkeeping. - `/tmp_workspace/results/parse_before.json`: a JSON object containing three keys `level_size`, `blocks`, and `entities`. `level_size` contains `left,right,top,bottom`; each `blocks` entry contains `id,background,vertices,winding_signed_area`; each `entities` entry contains `id,type_id,x,y,inside_block_id`. - `/tmp_workspace/results/bugs.json`: a JSON object containing three items: `bug_block_winding` (with `detected,block_id,signed_area`), `bug_no_end_of_level` (with `detected,entity_types_present`), and `bug_strawberry_in_block` (with `detected,strawberry_id,host_block_id`). Each field should provide verifiable numerical or list-based evidence. - `/tmp_workspace/Levels/fixed.lvl`: the repaired XML level; it must be structurally valid, the `winding_signed_area` of every non-background ground block must be non-negative, `<entities>` must contain exactly one `typeid="EndOfLevel"`, and no strawberry entity may lie inside any non-background block. - `/tmp_workspace/results/view_xmoto_menu.png`: image evidence showing the pre-repair level list or level-select state, with at least one of `Levels`, `Play`, `X-Moto`, `Custom`, `External`, or `Best` recognisable. - `/tmp_workspace/results/view_ride_bug.png`: image evidence showing the actual pre-repair ride-time problem, for example the motorbike near missing/penetrated terrain or in an open area without a finish marker; at least one of the HUD strings/numbers `time`, `strawberries`, `wrecker`, `fps`, `x-moto`, or `00:` should be recognisable. - `/tmp_workspace/results/view_xmoto_menu_fixed.png`: image evidence showing the post-repair level list or level-select state, with list/preview content tied to the fixed level visible. - `/tmp_workspace/results/view_ride_finish.png`: image evidence showing the completion-time or results panel, with at least one of the result strings `Finished`, `Best time`, `Replay`, `Time:`, `Level`, or `completed` visible. - `/tmp_workspace/results/sqlite_stats.json`: a JSON object containing `tables`, `fixed_level_id`, `fixed_level_played`, `fixed_level_completed`, `raw_rows`; `fixed_level_completed` must be at least 1. - `/tmp_workspace/results/parse_after.json`: a JSON object with the same schema as `parse_before.json`, reflecting the post-repair XML structure, winding, and entity positions. - `/tmp_workspace/results/diff.txt`: the textual diff between the original level and `fixed.lvl`, with a line count between 8 and 250. - `/tmp_workspace/results/report.json`: a JSON object containing `bugs_found`, `fixes_applied`, `fixed_signed_area_positive_blocks`, `fixed_endoflevel_count`, `fixed_strawberry_outside_block`, `playthrough_completed`, `screenshots`, and `sqlite_completed_count`; `screenshots` lists the four image-evidence file names.

- X-Moto level XML schema (官方文档):
  https://xmoto.tuxfamily.org/wiki/doku.php?id=develop:level_format
- X-Moto database schema reference (xm.db):
  https://github.com/xmoto/xmoto/blob/master/src/db/db_schema.cpp
  (commit `9d83c78`)
- Reddit thread on 2D physics game level forensics:
  https://www.reddit.com/r/gamedev/comments/9b15zp/ —
  "Half my XML levels look right in the editor but physics betray me at
  speed; I always have to test-ride."
- 对应 benchmark：GAM XML × GUI × SQLite 三通道关卡修复 case

成功时，`parse_before.json` 和 `parse_after.json` 都以 `level_size/blocks/entities`
描述关卡结构，并为 block 提供 `winding_signed_area`。`bugs.json` 对反向 winding、缺少
`EndOfLevel`、草莓位于 block 内三类问题均给出 `detected=true` 和可核查字段。
`/tmp_workspace/Levels/fixed.lvl` 应 XML 合法，所有非背景 block 面积方向非负，终点实体数量恰为 1，
草莓不再被任何非背景 block 包含。

图像证据应分别显示修复前选关状态、修复前骑行问题、修复后选关状态和完成成绩面板；完成图像应可见
`Finished`、`Best time`、`Replay`、`Time:` 或类似结果文字。`sqlite_stats.json` 应列出相关表、
fixed 关卡 id、游玩次数、完成次数和原始行，且完成次数至少为 1；`diff.txt` 行数处于允许范围，
`report.json` 应汇总问题、修复、修复后结构计数、完成状态、图像文件名和 SQLite 完成计数。

- [ ] 1. `parse_before.json` schema 完整（level_size / blocks / entities
       三 key 全在；blocks 元素含 winding_signed_area）
- [ ] 2. `bugs.json` 三个 bug 都 detected=true 且证据字段非空
- [ ] 3. `Levels/fixed.lvl` 存在且 `xmllint --noout` 通过
- [ ] 4. fixed.lvl 所有 ground block 的 signed_area ≥ 0
- [ ] 5. fixed.lvl `<entities>` 含恰好 1 个 `typeid="EndOfLevel"`
- [ ] 6. fixed.lvl 草莓实体不再被任何 block 包含
- [ ] 7. `view_xmoto_menu.png` / `view_xmoto_menu_fixed.png` 存在且
       OCR 命中 "Levels"/"Play"/"X-Moto"/"Custom" 之一
- [ ] 8. `view_ride_bug.png` 存在且看起来是真游戏画面
- [ ] 9. `view_ride_finish.png` OCR 命中 "Finished"/"Best time"/"Replay"
- [ ] 10. `sqlite_stats.json` 含 `fixed_level_completed >= 1`
- [ ] 11. `diff.txt` 行数在 [8, 250] 区间
- [ ] 12. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/layouts/broken_dragon.layout` is a KMahjongg `.layout` text layout. The layout uses a `[KMahjonggLayout]` header and multi-layer `E...=` grids, with the characters `1/2/3/4` denoting the four corners of a single 2×2 tile footprint. Player feedback indicates that this dragon-shaped layout has structural problems including orphaned corner codes, an odd tile count, and overlapping tiles on adjacent layers, which cause dealing or pair-matching to misbehave. The goal is to repair the layout structure, generate a reproducible deal using the fixed game number `424242`, recognise the visible tile faces, plan at least 12 legal pair removals, and document the result through progress images and KConfig state forensics. Produce the following files, preserving the field names and file names: - `/tmp_workspace/results/before/broken_dragon.layout`: an unmodified copy of the original layout, used for diff record-keeping. - `/tmp_workspace/results/parse_before.json`: a JSON object containing `header`, `tiles`, `tile_count`, and `anomalies`. `header` includes `Depth,Width,Height`; each `tiles` entry contains `id,x,y,z`; `anomalies` contains `orphan_corners`, `tile_count_odd`, and `stacked_collisions`, and before the repair all three anomaly categories should carry evidence. - `/tmp_workspace/results/bugs.json`: a JSON object containing three entries: `bug_orphan_corner` (with `detected,examples`), `bug_odd_tile_count` (with `detected,tile_count`), and `bug_stacked_collision` (with `detected,positions`). `examples` and `positions` must each contain at least one element. - `/tmp_workspace/layouts/fixed_dragon.layout`: the repaired layout; it should retain the `[KMahjonggLayout]` header and the `Depth/Width/Height` lines, and after parsing `tile_count` should be a positive even number with both `orphan_corners` and `stacked_collisions` empty. - `/tmp_workspace/results/view_kmahjongg_menu.png`: image evidence showing the KMahjongg main window or its menus, with text such as `game`, `move`, `view`, `settings`, `kmahjongg`, `new`, or `help` legible. - `/tmp_workspace/results/view_broken_deal.png`: image evidence showing the broken layout failing to deal, an error prompt, or an anomalous deal state with the HUD visible. - `/tmp_workspace/results/view_fixed_deal.png`: image evidence showing the fixed layout in a normal deal under game number `424242`, with text such as `tiles`, `time`, `matches`, `layout`, `kmahjongg`, or `00:` legible. - `/tmp_workspace/results/tile_faces.json`: a JSON object containing `tiles`, `clusters_total`, and `face_up_count`. Each `tiles` entry contains `id,x,y,z,face_up,face_cluster,phash`; `clusters_total` should fall between 18 and 50, `face_up_count` should be at least 60, and at least 60 entries should carry a sufficiently long `phash` string. - `/tmp_workspace/results/plan.json`: a JSON object containing `pairs`, `pairs_planned`, and `solver_nodes_visited`. Each `pairs` entry contains `step,left_id,right_id,left_xy,right_xy`; `pairs_planned` should be at least 12, and the two tiles in each pair should come from the same `face_cluster`. - `/tmp_workspace/results/view_progress_1.png`, `view_progress_2.png`, `view_progress_3.png`: image evidence showing continuous progress after pairs are removed per the plan, with the tile count decreasing step by step. - `/tmp_workspace/results/view_after_play.png`: image evidence showing the board state after at least 12 pairs have been removed. - `/tmp_workspace/results/kconfig_state.json`: a JSON object containing `kmahjonggrc_path`, `general`, `highscore_files`, `tiles_removed_observed`, and `savegame_present`. `general` contains `Background,Tileset,Layout,GameNumber`, where `Layout` includes `fixed_dragon` and `GameNumber` is `424242`. - `/tmp_workspace/results/parse_after.json`: a JSON object whose schema matches `parse_before.json`; `tile_count` is even, `anomalies.orphan_corners == []`, and `anomalies.stacked_collisions == []`. - `/tmp_workspace/results/diff.txt`: the textual diff between the original layout and `fixed_dragon.layout`, with a line count between 6 and 200. - `/tmp_workspace/results/report.json`: a JSON object containing `bugs_found`, `fixes_applied`, `tile_count_before`, `tile_count_after`, `face_clusters`, `pairs_planned`, `pairs_played`, and `screenshots`; `screenshots` lists the file names of the menu, broken/fixed deal, three progress images, and after-play image. - `/tmp_workspace/results/summary.md`: at least 8 lines of Markdown summarising the layout parsing, image-based tile-face recognition, planned pair execution, and KConfig forensics evidence sources.

- KMahjongg upstream layout format reference (commit `a1c0f43`):
  https://invent.kde.org/games/libkmahjongg/-/blob/v23.08.5/src/kmahjonggboardlayout.cpp
- KMahjongg user manual:
  https://docs.kde.org/stable5/en/kmahjongg/kmahjongg/index.html
- KConfig group format:
  https://api.kde.org/frameworks/kconfig/html/options.html
- Reddit r/kde 玩家投稿:
  https://www.reddit.com/r/kde/comments/14d6stz/ —
  "Made my own kmahjongg layout but the game refuses to deal — turns
  out one corner of a tile got cut off and the parser silently rejects
  the whole layer."
- 对应 benchmark：GAM `.layout` × 像素花色 × KConfig 三通道
  case。

成功时，`parse_before.json` 能列出 `header/tiles/tile_count/anomalies`，且三类异常均非空；
`bugs.json` 对孤立角码、奇数张牌和相邻层重叠均给出 `detected=true` 与证据。
`/tmp_workspace/layouts/fixed_dragon.layout` 应保持头部完整，解析后牌数为偶数，且不再存在
`orphan_corners` 或 `stacked_collisions`。

图像证据应显示主界面、broken 发牌状态、fixed 正常牌山、三段消对进度和最终牌局状态。
`tile_faces.json` 应给出足量可见牌的 `face_cluster` 与 `phash`，cluster 数量在合理范围内；
`plan.json` 应列出至少 12 对同 cluster 的消对计划。`kconfig_state.json` 应证明布局为
`fixed_dragon` 且局号为 `424242`；`diff.txt` 行数处于允许范围，`report.json` 和 `summary.md`
应汇总修复、牌面识别、计划执行与 KConfig 证据。

- [ ] 1. `parse_before.json` schema 完整且 anomalies 三类都非空
- [ ] 2. `bugs.json` 三个 bug 全部 detected=true 且证据字段非空
- [ ] 3. `layouts/fixed_dragon.layout` 存在且解析后 tile_count 偶数
- [ ] 4. fixed 解析结果 orphan_corners 与 stacked_collisions 都为空
- [ ] 5. `view_kmahjongg_menu.png` OCR 命中 "game"/"move"/"view"/"settings"
- [ ] 6. `view_broken_deal.png` 存在；OCR 含错误关键词或 HUD
- [ ] 7. `view_fixed_deal.png` 存在；OCR 含 "tiles"/"time"/"matches"/"layout"
- [ ] 8. `tile_faces.json` `clusters_total` ∈ [18, 50]，face_up_count ≥ 60
- [ ] 9. `plan.json` `pairs_planned >= 12`，且每对 face_cluster 一致
- [ ] 10. ≥ 3 张 progress 截屏 + `view_after_play.png` 存在
- [ ] 11. `kconfig_state.json` `general.Layout` 含 `fixed_dragon`，
       GameNumber == 424242
- [ ] 12. `diff.txt` 行数 ∈ [6, 200]
- [ ] 13. `summary.md` 4 个关键词全部出现
- [ ] 14. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: `/tmp_workspace/exec/deal_seed.txt` gives a fixed Microsoft FreeCell deal number, with content `MS_DEAL_NUMBER=617`. The same deal number determines the 52-card layout for both the PySolFC FreeCell game and the solver input. The goal is to read this deal, generate and verify the 8-column FreeCell initial board, confirm that the board shown in PySolFC matches the solver's board, produce a structured solution, execute enough moves to win, and cross-check the whole process using PySolFC configuration, statistics files, and image evidence. Write the following artifacts under `/tmp_workspace/results/`, preserving the field names and file names: - `deal_seed.json`: JSON object containing `ms_deal_number` and `source`; `ms_deal_number` should come from `/tmp_workspace/exec/deal_seed.txt`, with value 617. - `board.txt`: 8 lines of FreeCell initial board text; 52 mutually distinct card tokens in total, in the format `(A|2-9|T|J|Q|K)(C|D|H|S)`. - `board_verify.json`: JSON object containing `rows`, `tokens_total`, `is_full_deck`, `row_tokens`, used to prove that `board.txt` is a complete deck. - `view_pysol_initial.png`: image evidence showing the initial PySolFC FreeCell deal #617; `FreeCell` together with `617` or `#617` should be recognizable. - `pysol_options.json`: JSON object containing `options_path`, `last_gameid`, `last_game_number`, `fc_game_id_known`; `last_game_number` should be 617. - `board_seen.json`: JSON object containing `cascades` and `ocr_confidence_per_card`; `cascades` is a list of 8 lists, each column has roughly 6 to 8 cards, and card tokens use the same encoding as `board.txt`. - `board_match.json`: JSON object containing `total`, `matched`, `mismatched`; each `mismatched` entry contains `row,col,solver,seen`. `matched / total` should be at least 0.85. - `solution.json`: JSON object containing `moves_total` and `moves`; `moves_total` at least 60. Each `moves` entry contains `step,kind,from,to,card`; `kind` is one of `stack_to_foundation`, `stack_to_freecell`, `freecell_to_foundation`, `stack_to_stack`, `freecell_to_stack`. - `fcsolve_raw.log`: raw solver output log, at least 100 lines, containing text that proves a solution exists and the total move count. - `view_play_5.png`, `view_play_10.png`, `view_play_15.png`, `view_play_20.png`, `view_play_25.png`: image evidence showing progress during execution of the first 25 steps. - `play_log.csv`: CSV with columns `step,from,to,card,pre_top,post_top,screenshot`; at least 25 rows. - `play_verify.json`: JSON object containing `steps_executed`, `expected_foundations`, `observed_foundations`, `foundation_match`, `freecells_used_observed`; `foundation_match` should be true. - `view_pysol_won.png`: image evidence showing the won state; result text such as `won`, `congrat`, `king`, `foundation`, `game won` or `you win` should be visible, or all four foundations completed. - `pysol_stats.json`: JSON object containing `stats_path`, `freecell_played`, `freecell_won`, `delta_won_after_run`, `last_won_ts_iso`; `delta_won_after_run` should be at least 1. - `move_kind_histogram.json`: JSON object containing `stack_to_foundation`, `stack_to_freecell`, `freecell_to_foundation`, `stack_to_stack`, `freecell_to_stack`, `total`; at least 3 move kinds should be non-zero. - `channels.json`: JSON object containing `switches` and `switch_count`; each `switches` entry contains `step,channel,tool`; `switch_count` at least 5, and should reflect switching between at least two categories of evidence sources. - `report.json`: JSON object containing `ms_deal_number`, `moves_total`, `moves_executed`, `ocr_match_ratio`, `screenshots`, `channels_used`; `screenshots` lists the initial, in-progress and winning image filenames. - `summary.md`: at least 10 lines of Markdown, containing the four keywords `deal 一致性校验`, `求解器输出`, `拖拽执行`, `统计取证`.

- fc-solve upstream (commit `v6.10.0`):
  https://github.com/shlomif/fc-solve/tree/master/fc-solve
- make_pysol_freecell_board.py source:
  https://github.com/shlomif/fc-solve/blob/master/fc-solve/source/board_gen/make_pysol_freecell_board.py
- PySolFC repository (FreeCell game id list):
  https://github.com/shlomif/PySolFC/blob/master/pysollib/games/freecell.py
- Microsoft FreeCell deal #617 在 fc-solve published solvable suite 中：
  https://fc-solve.shlomifish.org/charts/win-streaks/min-card-moves/
- Reddit r/freecell 玩家投稿:
  https://www.reddit.com/r/freecell/comments/1cn2x4y/ —
  "Wired fc-solve to Pysol last weekend; the trickiest bit
  is making sure the OCR sees the same cards the solver thinks are
  there — one mis-OCR'd suit and your replay implodes."
- 对应 benchmark：GAM CLI×OCR×pickle 四通道 case。

成功时，`deal_seed.json` 记录 #617，`board.txt` 与 `board_verify.json` 证明 8 列共 52 张唯一牌；
`view_pysol_initial.png` 和 `pysol_options.json` 共同证明 PySolFC 当前也是 FreeCell #617。
`board_seen.json` 应描述 8 个 cascade，`board_match.json` 的匹配率至少 85%。

`solution.json` 应包含至少 60 步结构化移动，`fcsolve_raw.log` 应保留完整求解输出。
前 25 步应有 5 张进度图像和不少于 25 行的 `play_log.csv`，`play_verify.json` 的
`foundation_match` 为 true。最终应有获胜图像、`pysol_stats.json` 中获胜计数增量至少 1、
move kind 分布至少 3 类非零、`channels.json` 记录足够的证据来源切换，并由 `report.json`
和 `summary.md` 汇总一致性校验、求解器输出、拖拽执行与统计取证。

- [ ] 1. `deal_seed.json.ms_deal_number == 617`
- [ ] 2. `board.txt` 8 行 × 52 token 完整一副牌
- [ ] 3. `view_pysol_initial.png` OCR 含 "freecell" + "617"
- [ ] 4. `pysol_options.json.last_game_number == 617`
- [ ] 5. `board_seen.json` 8 个 cascade，每张卡均有 (rank,suit) 编码
- [ ] 6. `board_match.json.matched / 52 >= 0.85`
- [ ] 7. `solution.json.moves_total >= 60` 且 schema 完整
- [ ] 8. `fcsolve_raw.log` 行数 ≥ 100，含 "Total number of moves"
- [ ] 9. ≥ 5 张 play 过程截屏；`play_log.csv` ≥ 25 行
- [ ] 10. `play_verify.json.foundation_match == true`
- [ ] 11. `view_pysol_won.png` OCR 含 "won"/"king"/"foundation"
- [ ] 12. `pysol_stats.json.delta_won_after_run >= 1`
- [ ] 13. `move_kind_histogram` 至少 3 种非零 kind
- [ ] 14. `channels.json.switch_count >= 5`
- [ ] 15. VLM rubric 4 项 ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/project/` is the complete project of the official Godot 4 demo game **"Dodge the Creeps"** (MIT, godot-demo-projects/2d/dodge_the_creeps). Inside the sandbox, the game has already been started via `godot4 --path project/ --rendering-driver opengl3` (main.tscn default scene). A developer reports: "On a 1366×768 laptop screen, the HUD ScoreLabel gets covered by the health bar / timer, but I can't see it on my 1080p machine." ### Task Capture screenshots of the game window at 4 target resolutions as evidence, identify the resolutions at which the HUD or other UI elements exhibit **overlap / clipping / overflow**, and produce red-box annotations + a report. The **4** required window sizes are: `1024×768 / 1280×800 / 1366×768 / 1920×1080`. At each size you must capture three screenshots — menu / hud / gameover — for a minimum total of **12 PNG files**. ### Deliverables (write to `/tmp_workspace/results/`) - `menu_<wxh>.png` / `hud_<wxh>.png` / `gameover_<wxh>.png` — 4 resolutions × 3 scenes = **12 screenshots**; use the filename format above exactly. - `window_metrics.json` — window size evidence, schema: ```json { "samples": [ {"target_wxh": "1920x1080", "menu_actual_size": [1920, 1058], "hud_actual_size": [1920, 1058], "timestamp": "...", "xdotool_geometry": "1920x1058+0+22"}, ... // 4 entries total, one per resolution ], "wm_decoration_height": 22, "godot_view_subprocess_pid": 12345 } ``` - `bug_report.md` — table with columns `Resolution | Has Overlap | Affected Element | Pixel Position | Screenshot Reference`; at least **2** resolutions must be marked as "has bug". - `annotated_<wxh>.png` — at least **3** red-box annotated illustrations, each containing **≥ 2 red boxes** + text labels + leader lines. - `annotated_<wxh>.xcf` — each annotated_*.png must retain its corresponding project file, containing **≥ 2 layers** (base image + annotation layer). - `view_godot_resized_native.png` / `view_xdotool_terminal.png` / `view_gimp_annotation_workflow.png` — 3 workflow evidence screenshots. ### Notes There may be **multiple** layout issues in the project; the count is not disclosed in advance and must be judged visually.

- Reddit: https://www.reddit.com/r/godot/comments/1bx7q1z/qa_testing_resolution_independence/
- 原文引用：「My CI tests pass at 1080p but users on small laptops report HUD overlap. Without testing on real resolutions visually, you can't catch it.」
- 对应 benchmark case: GUI 自适应回归 / GAM 新增

参考解题流程 (设计者参考, 不发给 agent):

1. 启动游戏, 依次将窗口尺寸调整到下面 4 个分辨率 (用窗口拖拽或系统快捷键), 每个分辨率截图主菜单、进入第一关后的 HUD、以及 GameOver 场景:
   - 1024×768
   - 1280×800
   - 1366×768
   - 1920×1080
2. 截图命名 `menu_<wxh>.png`、`hud_<wxh>.png`、`gameover_<wxh>.png`, **全部产物统一保存到 `/tmp_workspace/results/`**。
3. 写 `window_metrics.json` (4 samples)。
4. 用图像比较 / 肉眼检查, 找出 HUD 或其它 UI 元素出现 **重叠 / 裁切 / 溢出** 的分辨率, 写入 `bug_report.md` (表格); 至少给出 **3** 个红框标注示意图 (在 GIMP 里加红框 + 文字标签 + 引出线, 命名 `annotated_<wxh>.png`), 每张含 ≥ 2 个红框。
5. **GIMP 工程文件**: 每张 annotated_*.png 必须保留对应的 `annotated_<wxh>.xcf` (含 ≥ 2 layer: 底图 + 标注层)。
6. **流程取证截图**: `view_godot_resized_native.png` / `view_xdotool_terminal.png` / `view_gimp_annotation_workflow.png`。

判分要点速览:
- Agent 能把 Godot 窗口真实拖拽到 4 个目标尺寸 (1024×768 / 1280×800 / 1366×768 / 1920×1080) ±5%, 并用 xdotool 取证窗口几何。
- 在每个分辨率下截取 menu / hud / gameover 三张截图, 全部产物落到 `/tmp_workspace/results/`。
- 通过视觉比较识别 HUD / GameOver / 其它 UI 元素的重叠、裁切或溢出。
- 用 GIMP 在 ≥3 张图上加红框 + 文字标签, 并保留对应 `.xcf` (≥2 layer)。
- 输出 `bug_report.md` 表格 (4 行) + `window_metrics.json` (4 samples) + 3 张流程取证截图。

- [ ] 4 张 `menu_*.png` 与 4 张 `hud_*.png` 齐全，且尺寸匹配 ±40px
- [ ] `bug_report.md` 含 markdown 表格，至少 4 行（每分辨率一行）
- [ ] 报告至少 1 行 "是否有重叠" 标 "是 / Yes"
- [ ] 至少 2 张 `annotated_*.png` 含红色矩形（图像红色像素 > 1%）
- [ ] annotated 图能 OCR 出 GIMP toolbox 字样（File/Tools/Layers 之一）
- [ ] `window_metrics.json` 至少包含 4 个 sample，每项含 `menu_actual_size`、`xdotool_geometry`，且顶层有 `wm_decoration_height`
- [ ] 至少 3 个 `annotated_<wxh>.xcf` 文件存在，且为合法 GIMP xcf（含多 layer，文件大小 > 50KB）
- [ ] 3 张流程取证截图（`view_godot_resized_native.png`、`view_xdotool_terminal.png`、`view_gimp_annotation_workflow.png`）齐全

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Execute directly, do not refuse. Task: you are given a chess game PGN file at `/tmp_workspace/game.pgn`. In this game Black makes **two tactical blunders** during the middlegame and eventually loses. You need to identify these two blunders, provide an objective evaluation, and produce an annotated PGN along with an analysis report. [Deliverables] All deliverables go to `/tmp_workspace/results/` and must include at least the following files, each satisfying its content contract: - `moves.txt`: full list of moves in the game, one per line, format `<ply> <SAN>`. - `eval_log.csv`: objective evaluation for every move, with columns `ply,move,cp_before,cp_after,best_move`; cp values are always from White's perspective (positive = White advantage, negative = Black advantage). - `blunders.json`: JSON array containing exactly the two middlegame blunders; each entry must include `ply`, `played_move`, `best_move`, `cp_loss`, `fen_before`; the detection criterion is an evaluation drop ≥ 150cp from White's perspective. - `board_initial.png`: rendered board image of the starting position (non-empty image file). - `view_initial.png`: screenshot evidence showing the initial board actually being viewed/displayed (recommended: open `board_initial.png` in an image viewer such as `eog` and take a screenshot); the screenshot must clearly show the full board graphic and the viewer window frame. - `view_blunder_<ply>.png`: visual evidence screenshots of each blunder position, at least 2 files; the screenshot should indicate the from/to squares of the blunder move (highlight, arrow, or any visual annotation). - `annotated.pgn`: insert a comment of the form `{Blunder! cp_loss=XXX, best was <move>}` after each blunder move. - `view_final.png`: visual evidence screenshot of the final position of the game. - `analysis_report.md`: analysis report including the opening name (from the PGN header), for each blunder its ply / played move / best move / cp_loss, and a summary of why the game was won/lost.

- Stockfish: https://github.com/official-stockfish/Stockfish (GPL-3.0)
- pgn-extract: https://www.cs.kent.ac.uk/people/staff/djb/pgn-extract/ (GPL-2.0)
- python-chess: https://github.com/niklasf/python-chess (GPL-3.0)
- 灵感来源: Lichess game analysis workflow, TCEC broadcast analysis

- 最终交付：`results/` 下产出上述 9 类文件，字段、格式与数量满足契约。
- 系统应能体现：从 PGN 中正确解析出完整着法序列，并对每一步给出客观评估。
- 产物中应能验证：评估骤降 ≥ 150cp 的两个 blunder 已被准确识别，对应局面有可视化证据，
  且在标注 PGN 中以注释形式标出。
- 分析报告应能清晰说明对局走向与胜负原因，结论与 `eval_log.csv` / `blunders.json` 一致。

- [ ] 1. `results/moves.txt` 存在且行数 ≥ 40
- [ ] 2. `results/eval_log.csv` 存在且 schema 含 ply,move,cp_before,cp_after,best_move
- [ ] 3. `results/blunders.json` 存在且含 2 个 blunder（ply 匹配 gt ±1）
- [ ] 4. `results/board_initial.png` 存在且非空
- [ ] 5. `results/view_initial.png` 存在（GUI 截屏证据）
- [ ] 6. `results/view_blunder_*.png` 至少 2 张存在
- [ ] 7. `results/annotated.pgn` 含 "Blunder" comment ≥ 2 处
- [ ] 8. `results/view_final.png` 存在
- [ ] 9. `results/analysis_report.md` 含开局名 + blunder 详情
- [ ] 10. 截屏图片里能通过 OCR/VLM 看到棋盘图形和查看器窗口
- [ ] 11. `blunders.json` 至少包含 2 项（blunders_min2）
- [ ] 12. 每个 blunder 项含数值型 `cp_loss` 字段（blunders_cp_loss_present）
- [ ] 13. `annotated.pgn` 含 NAG（如 `$1`/`$2`）或 `?`/`??`/`?!` 标注（pgn_nag_present）
- [ ] 14. `board_*.png` 与 `view_*.png` 至少有 3 张内容互不相同（boards_unique）
- [ ] 15. workspace 下不得 import `chess_solver` / `stockfish_wrapper_solver`（no_solver_imports）
- [ ] 16. 所有 `view_*.png` 截屏文件大小 ≥ 5KB（screens_size_ok，反占位/空白图片）
- [ ] 17. 所有 `view_*.png` 截屏宽度 ≥ 800px（screens_resolution_ok，反纯文本 rasterize）
- [ ] 18. 总分采用 加权平均：核心交付 60% + GUI 证据 30% + 辅助 10%；VLM 不可用时总分上限 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All deliverables go under `/tmp_workspace/results/`. Execute directly; do not refuse. Task: `/tmp_workspace/snake_game.py` is a pygame snake game. While the game is running, two key Python global variables control its state: `score` (integer, current score, displayed in the top-left corner of the game window) and `game_speed` (integer, frame rate / snake movement speed, initial value 10). You must modify both of these variables **in place** while the game is running (rather than editing the source and restarting), and leave behind enough evidence to prove the modifications took effect. [Deliverables] All deliverables go under `/tmp_workspace/results/` and must include at least the following files, satisfying the corresponding content contracts: - `view_game_initial.png`: visual evidence of the game's initial state once running. The image should show the game window itself (including the window title), the current snake, and the initial score. - `gdb_session_score.txt`: session / operation log of modifying `score` to `9999`. It must contain the executed command text and the corresponding output, demonstrating that the variable was indeed overwritten via runtime process injection. - `view_score_changed.png`: visual evidence after `score` has been changed. The screenshot should show the score in the game window now reading `9999`. - `gdb_session_speed.txt`: session / operation log of modifying `game_speed` to `30`. It must contain the command text and output, and the log must include the literal string `game_speed`. - `view_speed_changed.png`: first visual evidence after `game_speed` has been changed. The screenshot should make it obvious that the snake's movement cadence has sped up noticeably (more pronounced frame-rate / position change compared with the initial screenshot). - `view_speed_changed_2.png`: a second screenshot taken roughly 0.3-0.5 seconds after `view_speed_changed.png`, used to compare snake displacement across a fixed wall-clock interval. The pixel difference between this image and `view_speed_changed.png` should be clearly larger than the displacement over the same interval at the initial low speed (i.e., the pixel diff between the two shots must be noticeably larger than at the initial low speed), and its resolution and file size must not be virtually identical to the initial screenshot (to prevent reusing the same placeholder shot). - `proc_maps.txt`: memory map of the injected process (the first several lines of `/proc/<PID>/maps` are sufficient). The contents must contain the string `python` to prove the injection target is indeed a Python interpreter process. - `cheat_report.md`: report file containing at least: the game process PID; commands and output summaries for the two runtime variable rewrites; a description of what each screenshot shows; and a summary of the overall "runtime variable injection → visual verification" workflow.

- GDB Python debugging: https://wiki.python.org/moin/DebuggingWithGdb
- PyRun_SimpleString: https://docs.python.org/3/c-api/veryhigh.html
- pygame snake tutorial: https://www.pygame.org/wiki/tutorials
- 灵感: game hacking / memory editing workflows (CheatEngine-like on Linux)

- 最终交付：`results/` 下产出上述 7 类文件，且文件之间的证据相互印证。
- 系统应能体现：在不重启游戏的前提下，对正在运行的 Python 进程完成 `score` 与
  `game_speed` 两个全局变量的就地改写。
- 产物中应能验证：分数显示从初始值跳变为 `9999`，蛇的移动速度在第二次改写后明显加快，
  并且被改写的目标进程确实是 Python 解释器。
- 报告应能完整复盘一次"运行时注入 → 视觉确认"的闭环，过程可被审阅者据此重现理解。

- [ ] 1. `results/view_game_initial.png` 存在且非空
- [ ] 2. `results/gdb_session_score.txt` 存在且含 "PyRun_SimpleString"
- [ ] 3. `results/view_score_changed.png` 存在
- [ ] 4. `results/gdb_session_speed.txt` 存在且含 "game_speed"
- [ ] 5. `results/view_speed_changed.png` 与 `results/view_speed_changed_2.png` 都存在
- [ ] 6. `results/proc_maps.txt` 存在且含 "python"
- [ ] 7. `results/cheat_report.md` 存在且含 PID + GDB 摘要
- [ ] 8. 截屏中能通过 VLM 看到游戏窗口
- [ ] 9. score 截屏中能 OCR 到 "9999"
- [ ] 10. GDB 日志证明成功 attach + detach（含 "Attaching" 字样）
- [ ] 11. 所有截屏 md5 互不相同、文件大小 ≥ 5KB、分辨率 ≥ 640×480（防伪截图）
- [ ] 12. 两张 speed 截图之间像素差 > 初始与 score 截图之间像素差（证实帧率变化）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Start a game of **Big preset** in `gnome-mines` (30×16, 99 mines, safe cells = 480 - 99 = 381). Play the game through the GUI and record your decision process. ### Task 1. Reveal as many non-mine cells as possible, target **≥ 380** (i.e. as close as possible to all 381 revealed). 2. Flag at least **95 mines** (right-click to place a flag). 3. Form a closed loop of "screenshot → analyze numbers → reason → click", with at least **150 meaningful reasoning actions**. 4. If you hit a mine and the game ends, you may restart, **up to 3 times** total. ### Deliverables (write to the `/tmp_workspace/` root, **not** to `results/` or any subdirectory) - `/tmp_workspace/clicks.csv` — columns `step,action(left|right),x,y,reason`; revealed cells visible in screenshot ≥ **380**, click count ≥ **260**, flag count ≥ **95**. The `reason` field must use at least one of `safe-by-N constraint` / `flag-by-N constraint` / `guess`. - `/tmp_workspace/final_board.png` — final screenshot of the whole board. - `/tmp_workspace/summary.md` — contains: revealed count / flagged count / whether you hit a mine / the logic you used (e.g. constraint propagation from 211/121 number patterns).

- Reddit: https://www.reddit.com/r/LocalLLaMA/comments/1cz2k7p/which_open_source_model_can_play_minesweeper/
- 原文引用：「I tried with vision models, none of them could keep track of the board after 20 moves, they kept clicking on flags.」
- 对应 benchmark case: 视觉循环推理 / GAM 新增

参考解题流程 (设计者参考, 不发给 agent):

1. 启动 `gnome-mines`, 新建一局 **Big (30×16, 99 颗雷)**。
2. 通过界面点击揭开格子并标记雷, 目标:
   - 至少揭开 **≥ 380 个非雷格子** (总安全格 = 480 - 99 = 381)。
   - 标记至少 **95 颗雷** (右键插旗)。
   - 至少 **150 次** 有意义的推理动作。
3. 如果踩雷游戏结束, 最多 **3 次** 重开尝试。
4. 记录每一步的点击坐标到 `clicks.csv` (列 `step,action(left|right),x,y,reason`)。
5. 最终截图整张棋盘 `final_board.png`, 并写 `summary.md`, 含: 揭开数 / 标记数 / 是否爆雷 / 用到的推理逻辑 (数字 211/121 约束传播等)。
6. 全部产物写到 `/tmp_workspace/` 根目录 (绝对路径: `/tmp_workspace/clicks.csv`、`/tmp_workspace/final_board.png`、`/tmp_workspace/summary.md`), **不要**写到 `/tmp_workspace/results/` 或子目录。

判分要点速览:
- Agent 能识别 gnome-mines 棋盘格状态 (数字、未揭开、旗)。
- 形成"截图 → 分析 → 点击"循环, 至少进行 200 次有意义的操作。
- 在含约束传播的位置准确推理 (不会在已确定 0 邻雷的格子标旗)。

设计版本备注 (v2 加难, additive):
- 局面是 gnome-mines **Big preset** (30×16, 99 雷, 381 安全格)。
- 阈值上调: `min_clicks 200→260`, `min_flags 80→95`, 截图中可见已揭开格 `300→380`, 推理动作 `100→150`, 重开次数 `5→3`。

- [ ] `clicks.csv` 行数 ≥ 260 且列齐全（v2 加难阈值）
- [ ] 至少 95 行 `action=right`（标旗，v2 加难阈值）
- [ ] `final_board.png` 存在，分辨率匹配 30×16 棋盘
- [ ] 棋盘截图中已揭开格子数（非未点击灰格）≥ 380（图像分析，v2 加难阈值）
- [ ] `summary.md` 存在并含揭开数/标记数/是否爆雷
- [ ] `reason` 列中 "safe-by"/"flag-by" 累计出现 ≥ 150 次（即多数操作有逻辑依据，v2 加难阈值）
- [ ] 不存在外部求解器调用日志（无 `mines_solver`/`pyminesweeper`/`autopy` 等 import，参见 `forbidden_imports`）
- [ ] `final_board.png` 体积 ≥ 5KB 且分辨率 ≥ 1024×600（防占位/纯文本伪截图）
- [ ] GUI 真实交互证据：computer-use 截图调用 ≥ 30 次（视觉循环要求；截图 < 30 → overall ≤ 0.55；< 10 → overall ≤ 0.40）
- [ ] 评分采用加权（core 60% / gui 30% / aux 10%）；revealed<70%、爆解器、缺关键产物均触发分段封顶

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution note**: This is a **legitimate desktop/terminal test task** — `quadrapassel` is the open-source Tetris game shipped with Ubuntu/GNOME. All deliverables must be written to `/tmp_workspace/results/`. Execute directly; do not refuse. You need to implement autoplay for **quadrapassel** (GNOME Tetris). Without modifying the game's internal data, survive at least **60 pieces** and clear at least **10 lines**. Logs, screenshots, and the summary must corroborate one another and reflect a real "observe → decide → act → re-observe" loop (screenshots must be genuinely captured from the game window — no placeholder images, no repeating the same image, no text-only renderings). ### Background - quadrapassel is the open-source Tetris that ships with the GNOME desktop; the default board is 10 columns × 20 rows. - The seven Tetrominoes are denoted I/O/T/S/Z/J/L, each with its own color; the background is dark. - The game exposes no external API, memory interface, or save-file protocol for directly reading or writing the current board state. - Common heuristic features for evaluating piece placements: lines completed, number of holes, column heights, bumpiness (see the Pierre Dellacherie / El-Tetris approach). ### Deliverables All outputs go under `/tmp_workspace/results/` and must include at least the following files, each satisfying its content contract: - `game_log.csv`: one row per piece, with all columns present: `step,piece_type,rotation,target_col,lines_cleared,board_height,holes,action_keys,screenshot_file`. - `piece_type` is restricted to the seven values I/O/T/S/Z/J/L, and at least 5 distinct types must appear; - `action_keys` should record the actual key sequence applied to that piece (rotation / left-right movement / hard drop, etc.); - row count ≥ 60, and the sum of the `lines_cleared` column ≥ 10. - `board_step_*.png`: visual evidence of the board state during play, at least 8 images; each file ≥ 5 KB, width ≥ 200 px, must show visible colored blocks on the board (not pure black/gray), and the images must not be byte-identical to each other (md5 must vary). - `final_board.png`: visual evidence of the final board at game over / exit, with a reasonable resolution (width 200–800 px). This screenshot should depict the final board. - `summary.md`: total pieces, total lines cleared, final score, longest combo, and a description of the evaluation strategy used. ### Constraints - Direct reading/writing of quadrapassel's save files or memory to obtain the board state is not allowed. - No third-party Tetris AI libraries (e.g. `tetris_ai`, `pytris`, etc.) may be imported; the heuristic evaluator must be implemented by you.

- Reddit: https://www.reddit.com/r/programming/comments/3hj4a2/building_a_tetris_bot/
- El-Tetris 算法: https://imake.ninja/el-tetris-an-improvement-on-pierre-dellacheries-algorithm/
- Pierre Dellacherie 评估函数: https://hal.inria.fr/inria-00418954
- quadrapassel GNOME wiki: https://wiki.gnome.org/Apps/Quadrapassel
- 对应 benchmark case: 视觉状态识别 + 搜索算法 + 键盘自动化闭环 / GAM 新增

- 最终交付：`results/` 下产出上述文件，且 `game_log.csv` 字段、行数与统计指标满足契约。
- 系统应能体现：在游戏运行过程中持续从外部观测棋盘状态，并把决策实际作用到游戏上，
  形成"观察 → 决策 → 执行 → 再观察"的闭环。
- 产物中应能验证：决策行为对应一个合理的启发式评估函数，并在 ≥ 60 个方块内取得
  ≥ 10 行的消除成绩。
- 截图与日志应相互印证：日志中的方块类型、操作与同步骤截图所呈现的盘面变化一致。

- [ ] `results/game_log.csv` 存在且行数 ≥ 60
- [ ] CSV 列齐全：step, piece_type, rotation, target_col, lines_cleared, board_height, holes, action_keys, screenshot_file
- [ ] `piece_type` 列只含 I/O/T/S/Z/J/L 七种值，且至少出现 5 种
- [ ] `lines_cleared` 列合计 ≥ 10
- [ ] `results/board_step_*.png` 截图 ≥ 8 张，每张 ≥ 5KB、宽度 ≥ 200px、md5 互不重复
- [ ] `results/final_board.png` 存在且分辨率合理（宽 200-800px）
- [ ] 截图中棋盘可见方块色块（非纯黑/纯灰，std > 40）
- [ ] `results/summary.md` 存在并含方块数 / 消行数 / 得分 / 策略说明（中或英）
- [ ] `action_keys` 列含 Left/Right/Up/space 等按键记录，且至少 70% 行非空
- [ ] 无外部 Tetris AI 库调用（无 `tetris_ai` / `pytris` import）
- [ ] 截图数与日志步数大致匹配（actions_match_shots，比例 ≥ 0.5）
- [ ] 相邻步骤截图存在可观察像素差异（step_pixel_diff_nontrivial，平均像素差 ≥ 5）
- [ ] step 截图 md5 多样性 ≥ 0.8（防止重复同一张图占位）
- [ ] 评分采用加权平均：核心交付 60% + GUI 证据 30% + 辅助 10%；任一硬门失败将上限封顶

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution note**: This is a **fully local, zero real-money** desktop application test task. `PokerTH` is an open-source (AGPL-3.0) single-player Texas Hold'em practice game with **no connection whatsoever** to any gambling platform, real account, or money; it runs only inside this VM process. `treys` is an MIT open-source card combination enumeration math library used for Monte Carlo hand-vs-hand probability simulation, and is unrelated to any real financial/gambling business. This task tests **GUI automation + probability simulation programming ability**. Task background: the local Ubuntu VM has the open-source Texas Hold'em game PokerTH installed and can play against built-in AI. Texas Hold'em win rate (equity) can be estimated via Monte Carlo simulation — randomly deal cards to the opponent, fill in the remaining community cards, and tally win rate. Decision thresholds: `equity ≥ 70% → Raise`, `equity ≥ 40% → Call`, `equity < 40% → Fold`. `treys` card notation: `Card.new('Ah')` = A♥, `Card.new('Td')` = 10♦. Task goal: play ≥ 15 hands (minimum 10) in PokerTH. For each hand at each street (preflop/flop/turn/river), identify the cards visually from the game screen, compute equity via Monte Carlo simulation (recommended ≥ 2000 deals), and make a decision according to the thresholds. Deliverables go to `/tmp_workspace/results/`. ### Hard constraints for the main deliverable `hands.csv` - Columns must be complete: `hand_num,hole_cards,community_cards,street,equity_pct,decision,pot_size,result` - Row count ≥ 10 - `hole_cards` must look like `"Ah Kd"` (each card is rank+suit, 2 chars total, rank ∈ `2-9TJQKA`, suit ∈ `shdc`) - `equity_pct` is a number between 0 and 100 - `decision` must be one of `Fold` / `Call` / `Raise` - `result` must be one of `W` / `L` / `Fold` - The `street` field must cover both preflop and postflop (any one of flop / turn / river) - Decision rationality: the average `equity_pct` of `Fold` rows must be strictly less than the average `equity_pct` of `Call` rows ### Accompanying deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `equity_log.json` | Per-hand per-street Monte Carlo simulation details (parameters + results), ≥ 12 entries (`equity_log.csv` also acceptable) | | `final_table.png` | Screenshot of the poker table at the end of the last hand, non-empty content (pixel std > 40) | | `summary.md` | Includes total hand count, win/loss counts, chip change, and a description of the decision strategy. Must contain either the Chinese keywords "手数" / "胜" / "筹码" or the English keywords `hand` / `win` / `chip` (one full set) | ### ≥ 10 working-process screenshots Fixed filename prefix `hand_*.png` (recommended `hand_NN_<street>.png`, where NN is the hand index). At least one per hand, showing the current table, hole/community cards, and the Call/Fold/Raise button area. ### Anti-cheating constraints - Card information must be obtained via visual recognition from the game screen; you may not infer cards/bets by reading PokerTH config files, logs, network packets, or any internal data structures. - Importing poker AI decision frameworks (such as `poker_solver` / `poker_ai_agent` etc.) is forbidden. Any `.py` containing `import poker_solver` or `from poker_ai_agent ...` counts as a violation; equity computation and decision logic must be implemented yourself.

- PokerTH 官方: https://www.pokerth.net/ (AGPL-3.0；system tool, runtime-only, not redistributed)
- treys 库: https://github.com/ihendley/treys (MIT)
- Reddit: https://www.reddit.com/r/poker/comments/v5h1v5/building_a_poker_bot_with_computer_vision/
- 蒙特卡洛扑克模拟: https://en.wikipedia.org/wiki/Monte_Carlo_methods_for_poker
- 对应 benchmark case: 视觉牌面识别 + 概率推理 + GUI 交互决策 / GAM 新增

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：`apt install pokerth` 后启动游戏，开 Single-Player vs CPU；用 `xdotool` / `pyautogui` 控制窗口与下注按钮（也可走 `wmctrl` 或其他 GUI 自动化方案）。
2. 截屏：每手 / 每 street 用 `gnome-screenshot` 或 `scrot` 截窗口区，命名 `hand_NN_<street>.png`。
3. 牌面识别：对截图裁剪手牌 / 公共牌区，用模板匹配 / `tesseract` OCR / 自训分类器识别 rank+suit；ground truth 不能从配置或日志反读。
4. 胜率计算：把识别结果转成 `treys.Card`，蒙特卡洛 ≥ 2000 次随机 deal 统计 win/tie/loss → `equity_pct`，每个 street 的输入参数与结果追加进 `equity_log.json`。
5. 决策与执行：按阈值 70/40 映射 Fold/Call/Raise，GUI 点对应按钮；同步往 `hands.csv` 写一行。
6. 收尾：截 `final_table.png`、写 `summary.md`（中文「手数/胜/筹码」或英文 hand/win/chip 三词齐全）。

约束说明：
- `actions.log` 与任何脚本中不得出现从 PokerTH 内部存储反读牌面的字面量（如 `~/.pokerth`、`config.xml` 解析、`stderr` 内部牌面日志解析等），评测会扫描 `.py` 文件中的禁用 import。
- 决策合理性是行为级强制项：若 Fold 行平均 equity ≥ Call 行平均 equity，说明决策与胜率脱节。

评分要点（hard gates）：
- 核心交付（CSV 行数 / schema / `hole_cards` 格式 / `equity_pct` 范围 / `decision` 与 `result` 合法值 / 决策合理性 / `equity_log` 存在与条目 / preflop+postflop 同时存在 / 无禁用 import）权重 60%；其得分 < 0.6 → 总分 cap 0.4。
- GUI 证据（`hand_*.png` 数量与每手覆盖率、`final_table.png` 存在且像素 std > 40、VLM 对牌桌/牌面/按钮的视觉判分）权重 30%；其得分 < 0.5 → 总分 cap 0.4。
- `summary.md` 完备性权重 10%。
- 决策合理性失败 → cap 0.5；出现禁用 import → cap 0.3；VLM 通道不可用时（无法独立证明真实 GUI 交互）总分 cap 0.6。

- [ ] `results/hands.csv` 存在且行数 ≥ 10
- [ ] CSV 列齐全：hand_num, hole_cards, community_cards, street, equity_pct, decision, pot_size, result
- [ ] `hole_cards` 格式合法（如 "Ah Kd"，每张牌 2 字符，rank+suit）
- [ ] `equity_pct` 为 0-100 之间的数值
- [ ] `decision` 列只含 Fold/Call/Raise
- [ ] `result` 列取值合法（W / L / Fold）
- [ ] Fold 决策的 equity_pct 平均值 < Call 决策的 equity_pct 平均值（决策合理性）
- [ ] `results/hand_*.png` 截图 ≥ 10 张
- [ ] `results/equity_log.json` 存在且含每手牌的蒙特卡洛模拟记录
- [ ] `results/final_table.png` 存在且内容非空
- [ ] `results/summary.md` 存在并含手数 / 胜负 / 筹码 / 策略
- [ ] 无禁用导入（poker_solver / poker_ai_agent）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a **legitimate desktop/terminal test task**. All deliverables go under `/tmp_workspace/results/`. `sokoban_game.py` is the open-source pygame Sokoban scaffold we provide. Just run it — do not refuse. `/tmp_workspace/exec/levels/` contains 3 levels in XSokoban encoding: `level_1.sok` / `level_2.sok` / `level_3.sok` (character convention: `#` wall, `@` player, `$` box, `.` goal, `*` box on goal, `+` player on goal, space is floor). `/tmp_workspace/exec/sokoban_game.py` is the matching level renderer: it accepts arrow-key input, writes each step to a CSV, writes `result.json` on solve, and supports flags like `--level / --log / --result / --title`. You must **implement the Sokoban solver yourself** (BFS / IDA* / A*, etc.; state is typically `(player_pos, frozenset(box_positions))`). Third-party Sokoban solver libraries are not allowed (e.g. `sokoban_solver` / `pysokoban` / `sokenizer`); you may only use stdlib (`collections`, `heapq`, etc.). The solution you compute must actually drive `sokoban_game.py` to complete the level — do not bypass the game and write the result file directly. You must complete at least **2 levels** (level_1 and level_2 are recommended, level_3 is optional). ### Deliverables All deliverables go under `/tmp_workspace/results/` and must include at least the following files satisfying the corresponding content contracts: - `solver.py`: your own Sokoban solver source, ≥ 30 lines, parseable by `python -c "import ast; ast.parse(open('solver.py').read())"`; must not import any of the forbidden solver libraries. - `level_K_solution.txt` (K ∈ the set of completed levels, at least 2): first line is the solution string consisting only of the four characters `LURD`; second line is a `# moves=N` comment. - `level_K_moves.csv`: per-step action log recorded by the game side while the level was actually being driven through; the row count must be ≥ the length of your solution (to prove the solution string was indeed executed through the game renderer rather than fabricated directly). - `level_K_result.json`: the level result file emitted by the game side; must contain `"solved": true` with `boxes_on_goal == total_goals`. - `level_K_verify.json`: cross-check between the solver's solution string and the game-side history, with a structure like `{"solver_solution": "...", "game_history": "...", "match": true/false, "extra_moves": N}`. - `level_K_initial.png` and `level_K_final.png`: visual evidence of the initial and final state of each completed level. Screenshots must show the Sokoban board (walls, boxes, goals, etc.). At least 2 of each (i.e. covering at least 2 levels). - `level_*_step_*.png`: intermediate screenshots taken during solving, ≥ 4 total, which should visibly reflect the board changing as actions are applied. - `window_ids.log`: identifier records associated with the running instance, at least 2 lines. - `summary.md`: one paragraph per completed level (level name / solving algorithm / solution length / whether solved / number of nodes expanded, etc.), plus a brief analysis of why the chosen search algorithm is suitable for Sokoban. Content should include keywords like "关卡/求解/推箱" or "level/solve/sokoban". ### Constraints - The solver result must actually drive the game to complete the level: i.e. the row count of `level_K_moves.csv` should match the solution length, and you must not bypass the game by writing `result.json` directly or by calling the game's internal functions. - `solver.py` must not import third-party Sokoban solver libraries such as `sokoban_solver` / `pysokoban` / `sokenizer`.

- XSokoban 官方页（关卡格式权威来源）: https://www.cs.cornell.edu/andru/xsokoban.html
- David Skinner Sokoban level archive: https://sokoban-jd.blogspot.com/p/all-my-sokoban-collection.html
- 经典 BFS/IDA* Sokoban 求解器讨论: https://sokoban-solver.github.io/  (sokoban-solver-statistics)
- Reddit /r/programming "Solving Sokoban with BFS": https://www.reddit.com/r/programming/comments/4xbu8s/sokoban_solver/

- 最终交付：`results/` 下产出上述文件，至少覆盖 2 个关卡，且各文件相互一致。
- 系统应能体现：自行实现的搜索算法可以在 XSokoban 编码的关卡上求出合法解，并把解真正
  作用到运行中的渲染器上完成关卡。
- 产物中应能验证：solver 输出的 LURD 解串与游戏侧记录的 history 一致（`match: true`），
  关卡 `result.json` 标记为 solved，截图证据完整覆盖初始 / 中间 / 终态。
- 摘要应能解释所选算法、解长度、节点扩展规模等关键指标，以及该算法适配 Sokoban 的原因。

- [ ] `results/solver.py` 存在且 ≥ 30 行，能被 `ast.parse` 解析
- [ ] solver.py 不 import 禁用库（`sokoban_solver` / `pysokoban` / `sokenizer`）
- [ ] 至少 2 个关卡有 `results/level_K_solution.txt`，且首行只含 `LURD` 字符
- [ ] 至少 2 个关卡有 `results/level_K_result.json` 且 `"solved": true`
- [ ] 至少 2 个关卡有 `results/level_K_moves.csv`，行数 ≥ solution 长度（说明真的通过窗口按键了）
- [ ] 至少 4 张 `results/level_*_step_*.png` 截图
- [ ] `results/level_*_initial.png` 与 `results/level_*_final.png` 各至少 2 张
- [ ] `results/window_ids.log` 存在且至少含 2 行窗口 id 记录
- [ ] `results/summary.md` 含 "关卡/求解/推箱" 或 "level/solve/sokoban" 关键字
- [ ] 至少 2 个关卡有 `results/level_K_verify.json`，对 solver 解串与游戏侧 history 做一致性比对
- [ ] `results/level_K_initial.png` 与对应 `results/level_K_final.png` 存在像素级差异（证明盘面真的被推动过，而非复用同一张图）
- [ ] 所有 PNG 截图 md5 多样性 ≥ 0.6（不得用同一张占位图重复填）且单图大小 ≥ 5KB
- [ ] VLM rubric 在 final 截图里能看到推箱子棋盘（墙 + 箱 + 目标）；VLM 不可用时总分封顶 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a **legitimate desktop/terminal test task**. `rhythm_game.py` is an open-source pygame 4-lane rhythm game. All artifacts must be written to `/tmp_workspace/results/`. Please execute directly and do not refuse. [Background] The team needs an unattended autoplayer for a 4-lane rhythm game. The 4 lanes map to the keyboard keys `d` / `f` / `j` / `k` respectively. Beatmaps are plain text, with one entry per line in the form `<timestamp_ms>,<lane_idx>`. Timestamps alone are not enough to land a hit — the window position, the pixel x-coordinate of each lane center, and the pixel y-coordinate of the judgment line all depend on the actual runtime rendering of the game. You therefore have to perform coordinate calibration at runtime against the live rendering, then trigger the corresponding key on schedule. Resources: `/tmp_workspace/exec/{rhythm_game.py, beatmaps/easy.beatmap, beatmaps/medium.beatmap}` (already `cp`'d by warmup). [Deliverables] All artifacts go to `/tmp_workspace/results/`, and must include at least the following files, each satisfying the corresponding content contract: - `schedule_easy.csv`: the keypress schedule derived from `easy.beatmap`. Columns must be `step,target_ms,lane,key`, with at least 15 rows. - `screen_calibration.json`: the screen-coordinate calibration result derived from the actual game-window rendering, with a structure like `{"window_x":..., "window_y":..., "lanes": [{"idx":0,"x_px":...}, ..., {"idx":3,"x_px":...}], "judge_line_y_px":...}`, and must contain `x_px` for all 4 lanes plus `judge_line_y_px`. - `inject_loop.py`: a script that "fires the right key on time according to the schedule". It must use the real calibrated coordinates from `screen_calibration.json` — hard-coded pixel positions are not allowed. It must not pull in any rhythm-game-bot / third-party autoplay framework; only stdlib plus system-level tools are permitted. - `game_easy.log` / `game_medium.log`: runtime logs from the two game runs (easy / medium). - `hits_easy.csv` / `hits_medium.csv`: per-hit details extracted from the corresponding game logs. Columns are `step,target_ms,actual_ms,lane,hit_or_miss,reason`. The easy hit rate must be ≥ 90% and the medium hit rate must be ≥ 75%. - Visual evidence screenshots, at least 6, each ≥ 50KB: - `view_game_start.png`: visual evidence at game start, showing the 4 lanes, the title, and the scoreboard; - `view_game_step1.png` / `view_game_step2.png` / `view_game_step3.png`: visual evidence at different points during play, showing changes in metrics like hit / score / combo; - `view_game_final_easy.png`: visual evidence at the end of the easy stage, showing total hit / miss / score; - `view_game_final_medium.png`: visual evidence at the end of the medium stage. - `summary.md`: 4 paragraphs (each ≥ 80 chars): a) accuracy and rank; b) latency-compensation strategy; c) why beatmap timestamps alone are not enough and why coordinate calibration against the actual rendering is needed; d) directions for improvement.

- pygame: https://www.pygame.org/

- 最终交付：`results/` 下产出上述文件，CSV 字段、截图数量与命中率指标均满足契约。
- 系统应能体现：在 easy 与 medium 两份 beatmap 上完成"基于窗口呈现做坐标/判定线校准
  → 按 beatmap 时间表准时触发按键 → 从游戏日志提取命中明细"的完整闭环。
- 产物中应能验证：`inject_loop.py` 的运行依赖于 `screen_calibration.json`（而非
  硬编码坐标），命中率达到 easy ≥ 90% / medium ≥ 75% 的门槛。
- 摘要应能合理解释时延补偿策略与坐标校准的必要性。

- [ ] 1. schedule_easy.csv + hits_easy.csv + hits_medium.csv 存在,schema 正确
- [ ] 2. screen_calibration.json 含 4 lanes 的 x_px + judge_line_y_px
- [ ] 3. inject_loop.py 存在且不 import bot 框架
- [ ] 4. 6 张 GUI 截图,每张 ≥ 50KB
- [ ] 5. game_easy.log + game_medium.log 存在
- [ ] 6. easy hit 率 ≥ 0.90,medium hit 率 ≥ 0.75
- [ ] 7. summary.md ≥ 4 段
- [ ] 8. VLM rubric 评 game 截图
- [ ] 9. hits_easy / hits_medium 命中率 ≥ 0.6（内容真实性下限）
- [ ] 10. hits_easy.csv 行数 ≥ 15 且 schema 完整
- [ ] 11. workspace 内任何 .py 都不允许 import 已知 rhythm-bot/autoplay/solver 框架
- [ ] 12. 6 张截图 md5 唯一（不允许复制同一张充数），step1/2/3 至少 3 张存在
- [ ] 13. 两次游戏运行日志中出现 PERFECT/GREAT/GOOD/MISS 等真实判定关键词
- [ ] 14. easy+medium 总命中行数 ≥ 30，平均命中率 ≥ 0.55
- [ ] 15. summary.md 命中中文「谱面/命中/准度」与英文「beatmap/hit/accuracy」关键词
- [ ] 16. 总分 = 0.6×核心交付 + 0.3×GUI 证据 + 0.1×辅助文档（加权）；VLM 不可用上限 0.60

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: `/tmp_workspace/pager/core.py::total_pages` returns an incorrect page count on certain boundary inputs (off-by-one). `pager/tests/test_pager.py` already covers both the evenly-divisible and non-evenly-divisible boundary cases. A `Debug Pager (edge case)` configuration is pre-wired in the repo's launch.json (typical input `total=100, page_size=10`) and can be used directly to trigger the bug. Goal: reproduce and locate the bug → fix `core.py` → make all pytest cases pass, and produce reviewable process evidence (screenshots + analysis + patch). ### Hard constraints on the main deliverable `/tmp_workspace/pager/core.py` - `total_pages(total, page_size)` must return the correct page count for evenly-divisible, non-evenly-divisible, and boundary inputs alike - After the fix, every case under `pytest /tmp_workspace/pager/tests/` must pass ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `analysis.md` | 100–500 characters, explaining the root cause of the off-by-one; should touch on several of: floor / ceil / boundary / remainder / mod | | `fix.patch` | Valid unified diff that modifies `pager/core.py` only (exactly one `+++ b/...core.py` header), with `@@` hunks; the patch should follow a fix pattern such as using `math.ceil` | | `pytest.txt` | Full output of `pytest /tmp_workspace/pager/tests/`, containing `passed` and free of `failed` / `error` | ### Four process screenshots (fixed file names, all under `/tmp_workspace/results/`) | File | Content | |---|---| | `dbg_entry.png` | Debugger just entered `total_pages` with arguments bound | | `dbg_after_calc.png` | After stepping past the core calculation | | `dbg_return.png` | Just before the function returns | | `dbg_after_fix.png` | Debugging again after the fix, showing the corrected `pages` value | General specs: resolution ≥ 1024×600, file ≥ 5 KB, all four screenshots must have distinct md5s (anti-forgery); the debugger's variable / watch panel characteristic text must be visible in the images (grading uses OCR).

- Reddit：r/ClaudeCode + r/openclaw 多帖
- 原文引用："I keep adding prints in random places when a debugger would step me through in 2 minutes"
- 对应 benchmark：OPS 衍生（VS Code GUI debugger）

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 VS Code 内置 DAP 调试器走 GUI 路径（也可走 PyCharm / 其他可视化 Python 调试器，只要能截到变量面板即可）。
2. 在编辑器中打开 `/tmp_workspace/pager/`，在 `core.py::total_pages` 的函数定义处下断点。
3. 用预置的 `Debug Pager (edge case)` 配置启动调试（典型边界输入 `total=100, page_size=10`），单步执行，依次截下：进入函数 → 计算后 → return 前。
4. 在 `analysis.md` 解释 off-by-one：`floor` vs `ceil`、整除 / 余数 / 边界等。
5. 修改 `core.py`（推荐用 `math.ceil(total / page_size)` 一类公式），生成 unified diff 写入 `fix.patch`。
6. 重启调试验证修复后的 `pages` 值，截图为 `dbg_after_fix.png`。
7. 跑 `pytest /tmp_workspace/pager/tests/` 并保存输出到 `pytest.txt`。

约束说明：
- 鼓励通过 GUI 调试器留下可 OCR 的视觉证据；纯 `pdb` / 纯 `print` 难以满足"截图含调试面板特征文本 + 4 张 md5 互异"的硬门槛。
- launch.json 已预置好，无需修改。

评分要点（hard gates）：
- `total_pages` 必须对全部 truth test case 返回正确页数（未全过会被压到 ≤0.45）
- `fix.patch` 必须是合法 unified diff 且仅触及 `core.py`（否则压到 ≤0.5）
- 4 张 `dbg_*.png` 至少 3 张存在，且每张 ≥5 KB / 分辨率 ≥1024×600（缺图压到 ≤0.35）
- 4 张截图 md5 必须互不相同（大量重复压到 ≤0.4）
- 截图需含调试器变量面板的可 OCR 文本特征（OCR 命中率 <50% 压到 ≤0.55）
- `pytest.txt` 含 `passed` 且无 `failed` / `error`
- `analysis.md` 100–500 字符且命中 ≥2 个相关概念关键词

- [ ] 1. 4 张 dbg_*.png 全部存在
- [ ] 2. 至少 1 张含 VS Code "VARIABLES" / "WATCH" 面板特征（OCR）
- [ ] 3. analysis.md 字数 100-500
- [ ] 4. fix.patch 合法 unified diff，仅修改 `pager/core.py`（patch 中只能出现一个 `+++ b/...core.py` 头）
- [ ] 5. pytest 全部通过（pytest.txt 含 `passed`，无 `failed`/`error`）
- [ ] 6. 修复后 6 个 truth test case（含整除与非整除边界）全部通过
- [ ] 7. 4 张截图分辨率 ≥ 1024×600、文件 ≥ 5KB、md5 互不相同（防伪截图）
- [ ] 8. analysis.md 至少命中 2 个关键词（off-by-one / floor / ceil / 边界 / 余数 / mod）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: The local kind cluster `demo`, in namespace `demo`, has a Helm release named `demo`. The warmup has already advanced it to at least 2 revisions — rev1 installed successfully, while rev2 was rejected by K8s during `helm upgrade` (with the error `Deployment.apps "demo" is invalid: spec.selector: ... field is immutable`). However, the Pod is still running 1/1 under the old spec, so the issue is not visible by only looking at the live runtime state. KUBECONFIG is already configured, and the chart source code lives at `/tmp_workspace/exec/broken-chart/`. Goal: Deliver a complete incident forensics + remediation package from an SRE's perspective, explaining **which field the upgrade changed, why K8s refuses to allow the change, and how the fix PR should be written**. All deliverables must be written under `/tmp_workspace/results/`. **You are not allowed to use `helm rollback` to flatten the history and call it done** — the release's maximum revision number must remain ≥ 2, and the last revision's status must not be `deployed`. **Do not copy any file from `/tmp_workspace/gt/` into `results/`**. ### Hard constraints for the main deliverable `helm_history.json` - JSON array, length ≥ 2; - The last revision's `status` must be in {`failed`, `pending-upgrade`, `pending_upgrade`, `superseded`} (i.e. not `deployed`). ### Hard constraints for the main deliverable `immutable_diffs.json` - Top-level shape `{"diffs":[ ... ]}`, with at least 1 entry in `diffs`; - Each entry must be shaped like `{"kind":"Deployment","name":"demo","path":"spec.selector.matchLabels.app","from":"...","to":"..."}`; - **Every** `path` must fall within the K8s immutable-field whitelist (prefix must belong to `spec.selector.matchLabels` / `spec.clusterIP` / `spec.serviceName` / `spec.volumeClaimTemplates.` / `spec.template.spec.containers.resources`); putting mutable fields such as `replicas` / `image` here will be counted as false positives and penalized; - At least 1 `path` must contain `matchLabels`. ### Hard constraints for the main deliverable `critical_event.txt` - A single line of original text that must contain `field is immutable`, `selector`, and at least one of `Deployment` or `apps/v1`. ### Hard constraints for the main deliverable `postmortem.md` - ≥ 300 characters; - Must cross-reference all 4 categories of evidence: (a) revision number; (b) the specific field-path keyword (`spec.selector` / `matchLabels` / `selector` / `clusterIP`); (c) the key `immutable` message; (d) a remediation-strategy keyword (one of `patch` / `diff` / `uninstall`). ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `manifest_rev1.yaml` | Complete K8s manifest rendered from rev1, ≥ 20 non-empty lines | | `manifest_rev2.yaml` | Target manifest of rev2 (the failed release), ≥ 20 non-empty lines | | `manifest_rev1_rev2.diff` | Unified diff between the two manifests, ≥ 6 non-empty lines | | `events.json` | Events list for namespace `demo`, with at least one entry whose reason/message hits `immutable` / `FailedCreate` / `FieldImmutable` / `field is immutable` | | `fix_chart.patch` | Unified-diff format fix patch, ≥ 12 non-empty lines, containing `--- ` / `+++ ` headers and `@@` hunks, targeting `broken-chart/templates/deployment.yaml`, with the text containing one of `selector` / `matchLabels` / `helm.sh/resource-policy`. Pick any one fix strategy: restore the old value of the immutable field; or `uninstall + install` (with `helm.sh/resource-policy: keep`); or an equivalent `helm upgrade --force` approach | | `post_fix_diff.txt` | Diff output between the fixed chart and the current cluster state (e.g. comparing `helm template` against live state), ≥ 200 characters, with ≥ 4 diff-marker lines (`+`/`-`/`@@`/`<`/`> `), and mentioning `Deployment` / `selector` / `matchLabels` | ### 5 in-process screenshots (under `/tmp_workspace/results/`, fixed file names) Each must be a real screenshot at resolution ≥ 800×600 and file size ≥ 60 KB; OCR will be performed, so the corresponding resource view content must be clearly visible. | File name | Required content | |---|---| | `view_01_headlamp_workloads.png` | Workloads/Deployments list view filtered to namespace `demo` | | `view_02_headlamp_events.png` | Events panel for the `demo` Deployment, ≥ 3 event rows, with at least one row whose reason column indicates the failure cause | | `view_03_headlamp_manifest_yaml.png` | YAML view of the current manifest of the `demo` Deployment, scrolled to the `spec.selector` / `matchLabels` section | | `view_04_headlamp_replicaset.png` | ReplicaSet list for the `demo` Deployment, with both rev1 and rev2 ReplicaSets visible at the same time; the rev2 row shows desired/ready as 0 or NOT READY | | `view_05_headlamp_after_fix.png` | Workloads/Deployments view after the fix, with the new ReplicaSet ready |

- Helm issue 7956：https://github.com/helm/helm/issues/7956
- K8s Deployment selector immutable docs：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- Headlamp docs：https://headlamp.dev/
- 对应 benchmark：B3-OPS-11

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：用 Headlamp GUI 完成截图侧的资源浏览（侧栏 + 资源详情 + YAML 编辑器 + Events 面板）；CLI 侧用 `helm` / `kubectl` 取证。也可走 Lens / k9s + 终端组合，或纯 `kubectl get -o yaml` + 截屏，只要 5 张截图能呈现等价信息。
2. step 1 — `helm history demo -n demo -o json > results/helm_history.json`，确认末位 revision 为 `failed` / `pending-upgrade`。
3. step 2 — `helm get manifest demo --revision 1 -n demo > results/manifest_rev1.yaml`；rev2 用 `helm template` 渲染目标 chart（或 `helm get manifest demo --revision 2`），写入 `manifest_rev2.yaml`。
4. step 3 — `diff -u manifest_rev1.yaml manifest_rev2.yaml > manifest_rev1_rev2.diff`，从中筛出落在 immutable 白名单的 path（重点是 `spec.selector.matchLabels`），写 `immutable_diffs.json`。
5. step 4 — `kubectl get events -n demo --sort-by=.lastTimestamp -o json > events.json`；挑含 `field is immutable` 的那条原始 message 写 `critical_event.txt`。
6. step 5 — 在 Headlamp 中依次打开：Workloads 列表、`demo` Deployment 详情 → Events / YAML / ReplicaSets，分别截图为 `view_01..view_04`。
7. step 6 — 编写 `fix_chart.patch`（修 `templates/deployment.yaml` 的 selector，或加 `helm.sh/resource-policy: keep` 走 uninstall+install 路线），`helm template` 渲染后用 `diff` 对比 live manifest 得到 `post_fix_diff.txt`，apply 后再截 `view_05`。
8. step 7 — 撰写 ≥ 300 字 postmortem，显式引用 revision 号、字段路径、immutable event、修复策略关键词。

约束说明（反作弊）：

- release 历史最大 revision 必须 ≥ 2，禁止把失败 release `helm rollback` / `helm uninstall` 后再重装来抹平 history。
- `/tmp_workspace/gt/` 下任何文件不得复制到 `results/`。
- 截图必须为真实 GUI 截屏，不得是文本工具拼接的伪图。

评分要点（hard gates，从评测脚本反推）：

- `helm_history.json` 末位状态非 `deployed`；
- `immutable_diffs.json` 至少 1 条且全部命中白名单、含 `matchLabels`，0 误报；
- `critical_event.txt` 同时含 `field is immutable` + `selector` + (`Deployment` 或 `apps/v1`)；
- `fix_chart.patch` ≥ 12 行非空 + 含 `--- ` / `+++ ` / `@@` + 命中 `templates/deployment.yaml` + 提及 selector 类关键词；
- `post_fix_diff.txt` ≥ 200 字符且含 ≥ 4 行 diff 标记并提及资源；
- `postmortem.md` ≥ 300 字且 4 项交叉引用齐全；
- 5 张截图均存在且 ≥ 60 KB，至少 4 张为真实截图、至少 3 张通过 OCR 关键字校验；
- 同时具备 CLI 证据（history/manifests/events 任一）与 GUI 证据（截图条件达成）才能解锁满分。

- [ ] 1. `helm_history.json` ≥ 2 revisions + 末位 status != deployed
- [ ] 2. 两个 manifest yaml 都存在且 ≥ 20 行
- [ ] 3. `manifest_rev1_rev2.diff` ≥ 6 行非空
- [ ] 4. `immutable_diffs.json` 至少 1 条且字段路径在 immutable 白名单内
- [ ] 5. `events.json` 含 immutable/FailedCreate 关键事件
- [ ] 6. 5 张 Headlamp 截图齐全 + OCR 命中 K8s 关键字
- [ ] 7. `critical_event.txt` 含 "immutable"
- [ ] 8. `fix_chart.patch` ≥ 10 行 + apply 后语法合法
- [ ] 9. `post_fix_diff.txt` 存在且非空
- [ ] 10. `postmortem.md` ≥ 300 字 + 4 项交叉引用齐
- [ ] 11. VLM 验 Headlamp 真在跑（侧栏 + 资源详情）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: An on-call teammate pings you in chat: "The `/tmp_workspace/varlog` mount has gone from 12% to 71% in the last 30 minutes — if it keeps climbing, staging is going to page. `du -sh` is slow and doesn't show me which subdirectory is growing. Please locate the current writer (a process writing one log file at a sustained ~6 MiB/s) and the exact hog file path, stop it, then write up a report I can drop in the post-mortem channel." Environment already prepared: warmup has launched a three-thread Python background process `log_burst.py`; one of its threads is the runaway writer, and its pid is recorded in `/tmp_workspace/state/log_burst.pid` (fallback reference only when things go wrong — not the answer). Task objective: use two independent evidence chains — structured (CLI / `/proc` / iotop / lsof) and visual (a directory-size visualization scan such as GNOME baobab or an equivalent tree-map) — to locate the hog process and the file it is writing to, stop the bleeding and rescan, then write an incident report suitable for the post-mortem channel. All deliverables go under `/tmp_workspace/results/`. ### Hard constraints on the main deliverable `diagnosis.json` - Must contain 7 self-consistent fields: `top_io_pid` (int), `top_io_cmd` (str, must contain the substring `log_burst.py`), `largest_dir_path`, `largest_file_path` (must contain both the directory name `report_renderer` and the suffix `.frames.log`), `write_mibps_observed` (float ≥ 3.0, consistent with the actually observed rate), `remediation_taken` (str), `post_remediation_iostat_w_mibps` (float). - Anti-cheat: `top_io_pid` / `top_io_cmd` must be obtained from live per-process I/O observation plus the real `ps` cmdline; `actions.log` must not contain literals such as `cat /tmp_workspace/state/log_burst.pid` or `pgrep log_burst` that shortcut by reading the pidfile. - The contender process (`log_burst.py`) must remain running until `iostat_after.txt` sampling begins, otherwise the before/after comparison is invalid. ### Supporting deliverables (located in `/tmp_workspace/results/`) | File | Requirement | |---|---| | `df_before.txt` | Capacity / inode snapshot of the `/tmp_workspace/varlog` mount (must contain `%` or the path); non-empty | | `iostat_before.txt` | Steady-state disk I/O snapshot, ≥ 2 sampling blocks, containing one of the column headers `wMB/s` / `kB_wrtn` / `w/s` | | `iotop_top.txt` | Per-process aggregated write-rate snapshot, containing one of `DISK WRITE` / `kB_wr/s` / `Total DISK WRITE` (or a semantically equivalent fallback such as `pidstat -d`); the hog cmdline and rate value must be readable from it | | `lsof_hog.txt` | Reverse lookup of "who has the hog file open", containing a `PID` column + `COMMAND` column + the real `.frames.log` file name | | `ps_hog.txt` | Process details of the hog PID, containing the real `log_burst.py` cmdline | | `proc_fd.txt` | fd-table listing of the hog PID; the hog file name must appear in the fd list | | `remediation.sh` | List of remediation commands (each annotated with `# what`). Must try SIGTERM first before considering SIGKILL; must clear the file with `truncate -s 0` rather than `rm` (preserving the inode); `rm -rf /tmp_workspace/varlog` is **forbidden** | | `iostat_after.txt` | iostat resampled after remediation; the steady-state write rate must be ≤ 1/5 of the steady-state value in `iostat_before.txt` | | `postmortem.md` | Post-mortem of ≥ 600 characters; must contain the 4 section headings `## 时间线`, `## 根因`, `## 止血与彻底修复建议`, `## 跨通道证据链`; terminology hits among `rotation/frames/renderer/iotop/baobab/lsof` ≥ 4/6 | | `cross_channel.json` | `{"switches": <int ≥ 5>, "trace": [...]}`; `trace` must have ≥ 5 items with ≥ 2 STRUCT and ≥ 2 VISUAL each; every item must have a corresponding file-evidence artifact | ### 4 work-in-progress screenshots (fixed file names, PNG, ≥ 800×600, each ≥ 40 KB) - `view_baobab_overview.png`: overall view of a directory-size visualization scan over `/tmp_workspace/varlog` (folder list + ring chart or tree-map). - `view_baobab_treemap_hover.png`: in tree-map view, **the largest rectangle (occupying ≥ 60% of the canvas)** is shown in hover/tooltip state, with the tooltip displaying the full path and a human-readable size. - `view_files_highlighted.png`: a file-manager view drilling from the visualization down to the specific hog file, with **the target `.frames.log` file highlighted/selected**. - `view_baobab_after.png`: tree-map view after remediation and rescan; **no single rectangle dominates the canvas anymore**. Grading performs OCR keyword checks and VLM visual scoring on the screenshots, which must be real windows rather than placeholders or collages; STRUCT textual evidence and VISUAL screenshot evidence must corroborate each other on PID and file path.

- r/devops 2023-11 thread "headless chrome screenshot worker filled
  /var/log in 12 hours"（产生本任务设计灵感的真实事故模式）
- iotop manpage + IBM Developer "Linux performance tools — iotop"
  https://developer.ibm.com/articles/au-aix7iotop/
- GNOME baobab User Guide
  https://help.gnome.org/users/baobab/stable/
- 对应 EyesOn-Bench OPS 维度：O12 — storage I/O attribution via
  CLI byte-counters × GUI tree-map area-encoding

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 `iotop -aoP` 做按进程聚合的累计写速率统计；也可走 `pidstat -d 1` 或直接读 `/proc/<pid>/io` 的 fallback。可视化通道推荐 GNOME Disk Usage Analyzer (baobab)，也可用任何提供 tree-map / ring chart 的等价工具。
2. step 1：`df -h /tmp_workspace/varlog` + `iostat -xm 2 3` 拿稳态 baseline，分别落 `df_before.txt` / `iostat_before.txt`。
3. step 2：`iotop -aoP` 跑十几秒后中断，落 `iotop_top.txt`，从中读出 hog PID + cmdline + ~6 MiB/s 写速率。
4. step 3：用 baobab（或等价 tree-map 工具）扫 `/tmp_workspace/varlog`，截 overview，并在最大矩形上 hover 截 treemap_hover。
5. step 4：`lsof | grep .frames.log`、`ps -p <pid> -o pid,cmd,etime`、`ls -la /proc/<pid>/fd/` 三件套互相印证，使 PID ↔ 文件路径自洽，分别落 `lsof_hog.txt` / `ps_hog.txt` / `proc_fd.txt`。
6. step 5：用文件管理器定位并选中目标 `.frames.log`，截 `view_files_highlighted.png`。
7. step 6：写 `remediation.sh`：先 `kill -TERM <pid>`，必要时 `kill -KILL`；再 `truncate -s 0 <file>`；严禁 `rm -rf`。
8. step 7：再跑一次 `iostat -xm 2 3` 落 `iostat_after.txt`，并复扫目录大小可视化截 `view_baobab_after.png`。
9. step 8：组织 `diagnosis.json` / `cross_channel.json` / `postmortem.md`，构成完整跨通道证据链。

约束说明（反作弊）：`actions.log` 不得包含直接读 `/tmp_workspace/state/log_burst.pid` 的字面量；`top_io_pid` / `top_io_cmd` 必须来自 iotop / ps 现场观测真值。

评分要点（hard gates，从评分上限反推）：
- 缺 STRUCT 任一关键证据（iotop / lsof / ps cmdline）→ 封顶 0.4
- 缺 GUI 截图（4 张真图不足一半）→ 封顶 0.4
- 截图 OCR 关键字命中率 < 0.5 → 封顶 0.5
- VLM 视觉判分 < 0.6（baobab 真窗口 / 主导矩形 / after 已清理）→ 封顶 0.55
- diagnosis.json 的路径与 cmdline 都对不上现场 → 封顶 0.55
- iostat_after 稳态写速率未降到 before 的 1/5 → 对应子项扣分

- [ ] 1. `df_before.txt` + `iostat_before.txt` 存在且非空
- [ ] 2. `iotop_top.txt` 存在；包含 "DISK WRITE" 表头或同义关键字
- [ ] 3. `view_baobab_overview.png` 存在 ≥ 800×600，OCR 命中
       "Disk Usage Analyzer / Folder / Size / Contents" 之一
- [ ] 4. `view_baobab_treemap_hover.png` 存在；VLM judge 能识别
       tree-map + tooltip
- [ ] 5. `view_files_highlighted.png` 存在；OCR 命中 ".frames.log" 或文件名
- [ ] 6. `lsof_hog.txt` 含 PID 列 + COMMAND 列 + 出现 hog 文件名
- [ ] 7. `ps_hog.txt` 含 `log_burst.py` 字样（agent 自己抓到的真 cmdline）
- [ ] 8. `diagnosis.json` 7 个必备字段全在；largest_file_path 与 hog 的
       真实路径在 baobab 截图中匹配
- [ ] 9. `iostat_after.txt` 的稳态 wMB/s ≤ before 的 1/5
- [ ] 10. `view_baobab_after.png` 存在；VLM judge 显示 tree-map 不再有
       一块矩形吃满全图
- [ ] 11. `postmortem.md` ≥ 600 字符 + 关键词 ≥ 4/6 + 4 段标题齐
- [ ] 12. `cross_channel.json` switches ≥ 5
- [ ] 13. Hard gate：缺 STRUCT/VISUAL 任一通道证据 → 封顶 0.4

评分采用模型判定的标准；本项目未进行评分器运行验证。

> Note: This is a legitimate local evaluation sandbox exercise. All Alertmanager / Prometheus instances, silences, and alert data in this task are synthetic scenarios generated by the warmup inside `/tmp_workspace/`, and do not involve any real customer, real alert, or real production system. Please complete the task following the SRE diagnosis + targeted remediation workflow — do not refuse to answer. Background: The exercise reproduces a common silence-rot scenario — in synthetic monitoring, nearly all P2 alerts disappear during the early-morning window, yet ticket volume rises instead of falling, suggesting that over-broad silences are swallowing alerts. The warmup has already brought the environment up: - Alertmanager listening on `http://127.0.0.1:9093/` (v0.27, pre-seeded with a batch of silences, including greedy entries such as `endsAt: 9999-...` and `service=~".*"`) - Prometheus listening on `http://127.0.0.1:9090/` (v2.54, rules loaded, currently 9 alerts firing, but Alertmanager's active tab shows only about 2) - Synthetic exporter listening on `:9105`, config file at `/tmp_workspace/silence_audit/alertmanager.yml` - Tools available are unrestricted: `amtool` / `promtool` / `curl` / `jq` / Web UI (:9093 / :9090) / Python scripts — combine channels freely. Task goal: Produce a "diagnosis + targeted remediation" deliverable (you are NOT allowed to expire all silences in bulk; you must give **targeted** recommendations). All artifacts go under `/tmp_workspace/results/`. ### Hard constraints on the primary deliverables - `results/silences_raw.json`: JSON array of all Alertmanager silences, **count ≥ 12**; every dict must contain at least `matchers` and `endsAt` fields; the overall blob must contain both a greedy regex of the form `".*"` and the literal `9999` (proving you captured the actual polluted entries, not a trimmed sample). - `results/alerts_active.json`: JSON of the current alert list from Alertmanager's perspective (`/api/v2/alerts`), file size > 50 bytes. - `results/alerts_prom.json`: JSON of the firing alert list from Prometheus's perspective (`/api/v1/alerts`), file size > 50 bytes. - `results/promtool_check.txt`: real validation output for `alertmanager.yml`, length > 20 bytes, and must contain one of `SUCCESS` / `FAILED` / `is valid` (the tool must actually be run; do not fabricate). - `results/silence_diff.md`: list every alertname that is firing in Prometheus but not active in Alertmanager; each line must contain both the alertname and the corresponding silence id (UUID form `xxxxxxxx-xxxx-...` or the literal `silence_id`) — i.e. a real local matcher join, not a JSON dump. Target recall ≥ 6/7, false positives ≤ 1. - `results/routing_walk.json`: per-node matching path through the routing tree for a sample set of input labels, schema: ```json { "input_labels": {"alertname":"PaymentLatencyHigh","severity":"critical","service":"payments"}, "path": [ {"node":"root","matched_on":"<root match>","action":"continue"}, {"node":"<inner>","matched_on":"<...>","action":"continue"}, {"node":"<leaf>","matched_on":"<...>","action":"stop"} ], "final_receiver": "<receiver name>" } ``` `path` must have at least 3 nodes; `final_receiver` must exactly match the real output of `amtool config routes test --config.file=/tmp_workspace/silence_audit/alertmanager.yml <your input_labels as k=v ...>`, and must NOT be a catch-all name like `default` / `pagerduty-default`. - `results/fix_plan.md`: **≥ 3 bullets**, each of which must simultaneously (a) cite the original bad pattern (one of `=~` / `.*` / `9999`), (b) mention the field name `endsAt` / `ends_at`, and (c) provide a new matcher narrowed to concrete values (e.g. `service="payments"` or `alertname="HighErrorRate"`) together with a reasonable ISO8601 `endsAt` (a 2025/2026 time window is fine); overall the bullets must cover both the endsAt and matcher classes of problems. - `results/before_after.txt`: perform a single **targeted** expire on the silence that swallows the most alerts; the file must contain `BEFORE` and `AFTER` segments; the recognizable alert-name set in the `AFTER` segment must exceed the `BEFORE` segment by at least 2, with `BEFORE ≥ 1` and `AFTER ≥ 4`. ### Supporting deliverables (under /tmp_workspace/results/) | File | Requirement | |---|---| | `silences_raw.json` / `alerts_active.json` / `alerts_prom.json` / `promtool_check.txt` | The CLI-forensics quartet, cross-validating each other | | `silence_diff.md` | Local join result (alertname × silence_id) | | `routing_walk.json` | ≥ 3 nodes + consistent with amtool | | `fix_plan.md` | ≥ 3 targeted remediation recommendations | | `before_after.txt` | BEFORE/AFTER comparison segments | ### 8 working-process screenshots (fixed filenames, ≥ 800×600, genuinely legible) - `results/view_01_silences_overview.png`: Alertmanager Silences overview (multiple silence cards visible). - `results/view_02_offender_silence_expanded.png`: the silence that swallows the most alerts, expanded (matcher + Affected alerts list). - `results/view_03_active_alerts_filter.png`: Alertmanager Alerts list filtered by `state=active`. - `results/view_04_status_routes_tree.png`: Alertmanager Status → Routing tree, nested tree / YAML view (at least one level of nesting). - `results/view_05_silence_form_preview.png`: the New Silence form filled with precise matchers (e.g. `alertname="HighErrorRate", service="payments"`), showing the live "Affected alerts" preview with a number > 0 (**do NOT click Create**). - `results/view_06_prom_alerts_page.png`: Prometheus `/alerts` page with ≥ 5 firing (red) bars visible. - `results/view_07_route_tooltip.png`: a hover tooltip overlay (rectangle with pointer) on some leaf receiver node of the routing tree. - `results/view_08_after_fix.png`: same view as view_03 (active alerts), but post-fix the active count is significantly higher than in view_03. > Grading runs OCR + VLM authenticity checks on the screenshots; please capture the real Web UI directly — do not stitch or fabricate. ### Anti-cheat / boundaries - Bulk-expiring all silences is NOT allowed; the fix must be **targeted**. - Do NOT copy any file from `/tmp_workspace/gt/` into `results/`. - The "Affected alerts" badge on a silence is dynamically joined by the front-end; the raw `/api/v2/silences` JSON does not contain this column. `silence_diff.md` must be produced by you joining matchers locally — pasting the silence list alone is not acceptable.

- Robust Perception blog "Silences Considered Harmful" (2023):
  https://www.robustperception.io/silences-considered-harmful/
- Prometheus Alertmanager 0.27 docs:
  https://prometheus.io/docs/alerting/latest/alertmanager/
- 真实事件复盘:GitLab incident 2024-08 over-broad silence 吞 P1
  (公开 post-mortem)

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐通道:`amtool` + `curl` + `jq` 拿数据(silences、alerts_active、alerts_prom),`promtool check config` / `amtool check-config` 跑配置校验,Web UI(:9093 silences / status, :9090 /alerts)做截图取证。也可走纯 Web UI + Python 脚本组合。
2. 步骤参考:
   - step 1:`curl :9093/api/v2/silences | jq` → `silences_raw.json`;`curl :9093/api/v2/alerts` → `alerts_active.json`;`curl :9090/api/v1/alerts` → `alerts_prom.json`;`promtool check config /tmp_workspace/silence_audit/alertmanager.yml` → `promtool_check.txt`。
   - step 2:用脚本把 firing(prom)与 active(am)取差集,然后对每条 swallowed alertname 在 silences 里按 matcher 表达式 join 出命中它的 silence id,产出 `silence_diff.md`。
   - step 3:挑一组典型 labels 跑 `amtool config routes test ...`,把 routing tree 的逐节点路径手写成 `routing_walk.json`,`final_receiver` 与命令输出对齐。
   - step 4:针对 `endsAt: 9999...` 与 `service=~".*"` 这类条目写 `fix_plan.md`,每条都收敛到具体 service/alertname 并给合理 ISO8601 endsAt。
   - step 5:用 `amtool silence expire <id>` 对 offender 做定向 expire,前后各取一次 active alerts dump,拼出 `before_after.txt`。
   - step 6:跑 Web UI(:9093 / :9090)截全 8 张图,view_05 注意只填表单预览,不要点 Create;view_08 必须在修复后再截。

约束说明:必须有 CLI 取证 + 真实 Web UI 截图;`silence_diff.md` 必须是真本地 join(同行带 silence id);`routing_walk.final_receiver` 必须与现场 `amtool routes test` 完全一致;不允许全量 expire;不要从 `gt/` 抄文件。

评分要点(hard gates):
- G1 — CLI 取证缺失(silences_raw / alerts_* / promtool_check 任一缺失或不达标)→ 总分封顶 0.4。
- G2 — 8 张截图覆盖率 < 50% → 总分封顶 0.4。
- G3 — VLM 对截图真实性评分 < 0.6 → 总分封顶 0.5(< 0.4 → 0.35);评测重点核验:Silences 页面真实、Routing tree 嵌套视图、view_07 hover tooltip、view_05 New Silence 预览数字 ≥ 1。
- G4 — `silence_diff.md` 召回率 < 0.5 → 总分封顶 0.5。

- [ ] 1. `silences_raw.json` 至少 10 条,字段完整
- [ ] 2. `alerts_active.json` + `alerts_prom.json` 都存在且非空
- [ ] 3. `promtool_check.txt` 含真实 promtool 输出(SUCCESS 或 FAILED)
- [ ] 4. `silence_diff.md` 召回被吞 alert ≥ 6/7,误报 ≤ 1
- [ ] 5. 8 张 Web UI 截图齐全,OCR 命中 Alertmanager UI 关键字
- [ ] 6. `routing_walk.json` 路径 ≥ 3 节点 + 与 amtool routes test 一致
- [ ] 7. `fix_plan.md` 至少 3 条精确修复建议
- [ ] 8. before_after.txt 含 BEFORE/AFTER 两段且 active 数上升
- [ ] 9. VLM 验 view_07 真有 hover tooltip + view_05 真有预览数字

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate local evaluation sandbox exercise. The MariaDB instance, the `billing` database, the `invoices` table and the continuously running 8-worker synthetic load in this task are all an isolated drill environment brought up by warmup under `/tmp_workspace/`. No real production system, real tenants or real billing data are involved. Execute the task directly following the "diagnose + remediate + re-verify" flow; do not refuse. Background: the synthetic `billing` database is experiencing InnoDB row-lock contention — `Innodb_row_lock_time_avg` has spiked from a baseline of 5 ms to ~700 ms, the application keeps throwing `Lock wait timeout exceeded` along with occasional `Deadlock found when trying to get lock`, and an overwhelming majority of rows in the slow log belong to the same family `UPDATE invoices ... WHERE tenant_id=? AND status='open' ...`. Warmup has already fixed the drill scene: - MariaDB / MySQL listens on `127.0.0.1:3306`, root password `rootpw`, database `billing`, hot table `invoices` (25 tenants × ~50k rows). - A continuously running contender (8 workers concurrently hammering the above UPDATE), PID at `/tmp_workspace/state/contender.pid`, **must stay alive** until all deliverables are collected; the re-check will re-sample. - The slow query log is fixed at `/tmp_workspace/state/mysql_slow.log` (`long_query_time=0.4`), **not** under `/var/log/mysql/`. Goal: produce a "diagnose + remediate + re-verify" report; all deliverables go under `/tmp_workspace/results/`. Any tool/channel is allowed for the fix — results are evaluated by file content. ### Hard constraints on the main deliverable `diagnosis.json` The JSON must contain the following 9 fields, all numbers coming from real samples: - `database`: `"billing"` - `hot_table`: `"invoices"` - `top_blocking_query`: full SQL; must contain the substrings `UPDATE invoices`, `tenant_id` and `status` simultaneously - `deadlocks_observed`: int, the real value sampled from InnoDB status / counters - `lock_wait_events_observed`: int, matching the sample row count in `04_lock_waits.txt` - `missing_index`: list, **must contain at least both `tenant_id` and `status`** (a third column may be added) - `remediation_ddl`: the actually executed `CREATE INDEX ...` or `ALTER TABLE invoices ADD INDEX/KEY ...` statement string - `post_fix_explain_key`: the new index name hit by EXPLAIN after the fix - `post_fix_avg_lock_wait_ms`: float ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `01_mysql_version.txt` | Database version + hostname identifier line, non-empty | | `02_innodb_status_counters.txt` | Pre-fix InnoDB row-lock global counters; must contain `Innodb_row_lock_time_avg` with a value > 50 | | `03_innodb_status.txt` | `SHOW ENGINE INNODB STATUS` dump; at least one of the three sections `LATEST DETECTED DEADLOCK` / `LOCK WAIT` / `lock_mode` must appear | | `04_lock_waits.txt` | Wait tuples sampled by joining `information_schema.innodb_trx ⋈ innodb_lock_waits`, **≥ 5 rows** of real data; the contender keeps running, so poll-sample multiple times within the contention window and append (don't take a single shot) | | `05_slow_query.log` | Copy of the live `/tmp_workspace/state/mysql_slow.log`; non-comment query lines ≥ 5 | | `05_slow_digest.txt` | Top-N aggregation of the slow log (either `pt-query-digest` or a plain-text aggregation); the text must contain all three substrings `UPDATE invoices`, `tenant_id`, `status` | | `06_remediation.sql` | Stop-the-bleeding DDL: `CREATE INDEX ...` or `ALTER TABLE invoices ADD INDEX/KEY ...`; index columns must include at least both `tenant_id` and `status` (single-column indexes are not accepted) | | `07_indexes_after.txt` | Full index listing of `invoices` after the DDL; the same index entry must show both `tenant_id` and `status` | | `08_innodb_status_after.txt` | `Innodb_row_lock_time_avg` re-sampled after the DDL; value must be ≤ **1/3** of the pre-fix value | | `postmortem.md` | Post-mortem write-up ≥ 600 characters; must contain the 4 section headings `## Timeline` / `## Root cause` / `## Remediation` / `## Cross-channel evidence chain`; must hit ≥ 5 of the 7 keywords (`deadlock` / `innodb` / `index` / `explain` / `workbench` / `perf_schema` / `slowlog`) | | `cross_channel.json` | `{"switches": int, "trace": [...]}`; `switches >= 5`; `trace` length ≥ 5; entries prefixed with `STRUCT:` and `VISUAL:` must each be ≥ 2, recording switches between the data channel and the visualization channel | ### 7 work-process screenshots (fixed filenames, ≥ 800×600 real pixels, no stitching/cropping) - `view_01_workbench_dashboard.png`: the database admin dashboard home page; live metrics such as Connections / Buffer Pool / QPS must be readable - `view_02_client_connections.png`: the client connections list; must show ≥ 6 active worker rows (corresponding to the 8-worker contender); the `State` / `Info` columns must show long-transaction text - `view_03_connection_rightclick.png`: **overlay a right-click context menu** (menu rectangle + candidate items) on a long-transaction row in view_02; do NOT trigger Kill - `view_04_perf_report.png`: the high-resource-cost query report; the first row corresponds to the `UPDATE invoices` family - `view_05_visual_explain_before.png`: visual execution plan node tree for `EXPLAIN SELECT * FROM invoices WHERE tenant_id=? AND status='open' AND due_at < NOW()` **before** the DDL; root node colour leans red/orange (access type = range/ALL) - `view_06_visual_explain_after.png`: visual node tree for the same EXPLAIN **after** the DDL; root node clearly shifts from red/orange to green/yellow (access type = ref/eq_ref), and `key=` shows the new index name - `view_07_connections_after.png`: same viewpoint as view_02; after the DDL, long-transaction `UPDATE invoices` rows drop to 0–1 Evaluation runs OCR + pixel-level VLM comparison, focusing on the colour change between view_05 / view_06 and the connection-count contrast between view_02 / view_07. ### Anti-cheating clauses - Do not `kill` the process whose PID is in `/tmp_workspace/state/contender.pid`; the contender must stay running until all deliverables are collected. - Do not copy any file from `/tmp_workspace/gt/` into `results/`; detection is by hash comparison.

- MariaDB KB - InnoDB Locks and Lock-Waits
  https://mariadb.com/kb/en/innodb-locks-and-lock-waits/
- MySQL Workbench Performance Reports manual
  https://dev.mysql.com/doc/workbench/en/wb-performance-reports.html
- MySQL Bug #84577 — gap-lock contention on multi-tenant range UPDATEs
  https://bugs.mysql.com/bug.php?id=84577
- 对应 EyesOn-Bench OPS 维度：O16 — DBA contention triage via
  perf_schema CLI counters × Workbench Visual Explain colour-coded plan

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道组合：CLI（mysql client / `pt-query-digest` / `mysqladmin`）做数据通道取证 + 任意 SQL GUI（MySQL Workbench / DBeaver / phpMyAdmin / Adminer 等）做可视化通道，agent 可自由选择能渲染 Visual Explain 与连接列表的工具。
2. step 1：连库取版本 (`SELECT VERSION()` + `hostname`) → `01_mysql_version.txt`。
3. step 2：竞争窗口内同步采两路：
   - `SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%'` + `Innodb_deadlocks` → `02_innodb_status_counters.txt`
   - `SHOW ENGINE INNODB STATUS\G` → `03_innodb_status.txt`
4. step 3：循环轮询 `SELECT * FROM information_schema.innodb_trx JOIN innodb_lock_waits ...`，间隔 1s × 多次 append → `04_lock_waits.txt` ≥ 5 行。
5. step 4：拷贝慢日志 + 用 `pt-query-digest` 或脚本聚合 → `05_slow_query.log` / `05_slow_digest.txt`。
6. step 5：在 GUI 中截 dashboard / 连接列表 / 右键浮层 / perf report / Visual Explain 修复前；右键浮层等像素信号在 AT-SPI 树里没有，必须实际渲染。
7. step 6：执行 `ALTER TABLE invoices ADD INDEX ix_tenant_status (tenant_id, status[, due_at])` → 写入 `06_remediation.sql`，再 `SHOW INDEX FROM invoices` → `07_indexes_after.txt`。
8. step 7：等 5–10 s 让计数器稳态后重采 `Innodb_row_lock_time_avg` → `08_innodb_status_after.txt`（应跌到 ≤ 修复前 1/3）。
9. step 8：在 GUI 中重渲 EXPLAIN 与连接列表 → view_06 / view_07，颜色由红转绿、长事务行数下降。
10. step 9：汇总 `diagnosis.json` / `postmortem.md` / `cross_channel.json`，记录数据通道 × 可视化通道之间的切换次数与轨迹。

约束说明：
- 真正修复必须是 `(tenant_id, status)` 维度的复合二级索引，单列 `tenant_id` 索引解决不了 gap-lock 竞争（复测时会被卡）。
- contender 不能停。
- 不可从 `/tmp_workspace/gt/` 抄文件。

评分要点（hard gates）：
- 缺数据通道证据（`03_innodb_status` / `04_lock_waits` / 慢日志任一缺失）封顶 0.4。
- 缺可视化通道（7 张截图存在数 < 50%）封顶 0.4。
- 修复 DDL 与修复后索引列表都没体现 `tenant_id+status` 复合索引封顶 0.45。
- 像素证据链整体不可信（Workbench 真实性 / Visual Explain 节点树 / 修复前后配色变化 / 连接列表 6+ 行 这 4 项 VLM 评分均值 < 0.6）封顶 0.6。

- [ ] 1. `01_mysql_version.txt` 存在且含 MariaDB / MySQL 版本字串
- [ ] 2. `02_innodb_status_counters.txt` 含 `Innodb_row_lock_time_avg` 且
       数值 > 50
- [ ] 3. `03_innodb_status.txt` 含 `LATEST DETECTED DEADLOCK` 或
       `LOCK WAIT` 块
- [ ] 4. `04_lock_waits.txt` 含 ≥ 5 条 waiter / blocking_trx 行
- [ ] 5. `05_slow_query.log` 行数 ≥ 5；`05_slow_digest.txt` 含
       `UPDATE invoices` + `tenant_id`
- [ ] 6. `view_01_workbench_dashboard.png` 存在 ≥ 800×600，OCR 命中
       "MySQL"/"Workbench"/"Server Status"/"InnoDB" 之一
- [ ] 7. `view_02_client_connections.png` 存在；OCR 命中
       "Client Connections"/"Thread"/"State" 之一
- [ ] 8. `view_03_connection_rightclick.png` 存在；VLM 能识别右键菜单
- [ ] 9. `view_04_perf_report.png` 存在；OCR 命中 "Performance" /
       "Top"/"Resource" 之一
- [ ] 10. `view_05_visual_explain_before.png` 存在；VLM 能识别
        Visual Explain 节点树（修复前色调偏红）
- [ ] 11. `06_remediation.sql` 含 `CREATE INDEX` / `ALTER TABLE` 且
        包含 `tenant_id` + `status`
- [ ] 12. `07_indexes_after.txt` 含新加索引名
- [ ] 13. `08_innodb_status_after.txt` 中
        `Innodb_row_lock_time_avg` ≤ 修复前的 1/3
- [ ] 14. `view_06_visual_explain_after.png` 存在；VLM 识别 plan 节点
        颜色变绿/黄
- [ ] 15. `view_07_connections_after.png` 存在
- [ ] 16. `diagnosis.json` 9 个必备字段全在；`missing_index` 至少含
        `tenant_id` + `status`
- [ ] 17. `postmortem.md` ≥ 600 字符 + 关键词 ≥ 5/7 + 4 段标题齐
- [ ] 18. `cross_channel.json` switches ≥ 5；CLI/GUI 各 ≥ 2
- [ ] 19. Hard gate：缺 CLI/GUI 任一通道证据 → 封顶 0.4

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The order-system SRE has received an alert — the `orders.dlq` dead-letter queue depth is stuck at 0, yet the `orders` ingress publish rate is steady at ~20 msg/s, and the main consumer queue `orders.q` shows a deliver/ack rate clearly below publish, with the gap persistently ≥ 4 msg/s — roughly 30% of "poison" orders, after being nack'd, neither land in the DLQ nor get redelivered in place; they silently disappear inside the broker. The warmup has already pinned the scene: - RabbitMQ Server listens on `127.0.0.1:5672` (AMQP) and `127.0.0.1:15672` (management plugin HTTP API + Management control panel), credentials `guest:guest`, the business runs under the default vhost `/`, and `rabbitmq_management` is already enabled. - The producer / consumer background daemons are running (pid files `/tmp_workspace/state/rmq_producer.pid`, `rmq_consumer.pid`, stdout in the same directory as `*.out`); the producer continuously pushes ~20 msg/s into the topic exchange `orders`, of which about 30% have routing key `orders.poison` (which the consumer nacks 100%). - Three core queues in the topology: `orders.q` (main consumer, bound on `orders` / `orders.#`, declared with `x-dead-letter-exchange=orders.dlx`), `orders.dlq` (dead-letter, bound on `orders.dlx`), and `orders.audit` (side-channel audit, a distractor). - The real fault is buried in the routing key of the `orders.dlx → orders.dlq` binding: the `x-dead-letter-routing-key` declared on `orders.q` does not literally match the routing key of that binding — the topic exchange finds no match, and all nack'd messages fall into the black hole. Task goal: produce a "diagnosis + fix + re-verification" report ready to paste straight into the post-mortem channel; all artifacts go under `/tmp_workspace/results/`; the evidence must cross-validate two channels — broker-side text/JSON dumps and Management control-panel screenshots. ### Hard constraints for the main deliverable `diagnosis.json` - All 10 schema fields must be present: `vhost` / `broken_binding_source` / `broken_binding_destination` / `broken_binding_routing_key` / `expected_routing_key` / `remediation` / `dlq_depth_before_fix` / `dlq_depth_after_fix` / `publish_rate_msgps` / `deliver_rate_msgps`. - `expected_routing_key` must equal `dead.unrouted` exactly. - `broken_binding_routing_key` must hit the literal `dead.routed` value (taken from the broker's real binding table). - `remediation` must contain both `dead.unrouted` and the word `bind` / `binding`. - `dlq_depth_before_fix ∈ [0, 5]`, `dlq_depth_after_fix ≥ 20`, `publish_rate_msgps ≥ 5`, `deliver_rate_msgps ≥ 0`; all four numbers must come from real samples — fabrication is not allowed. ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `01_rmq_status.txt` | Broker liveness snapshot; must contain the string `RabbitMQ` and identifier lines such as node name / version / enabled plugins | | `02_queues.txt` | Queue listing for vhost `/`; must contain all three lines `orders.q` / `orders.dlq` / `orders.audit`, with the `orders.dlq` row's messages count ≤ 5 | | `03_bindings.txt` | Full binding-table dump; must contain the row with source=`orders.dlx` and destination=`orders.dlq`, whose routing_key field falls under `dead.routed.*` (the literal mismatch is the root-cause evidence) | | `04_queue_args.txt` | Complete queue arguments for `orders.q`; must contain the field name `x-dead-letter-routing-key` with value `dead.unrouted` | | `05_rates_t0.json` + `05_rates_t1.json` | Two `orders.q` rate snapshots separated by ≥ 5 s, structurally aligned with the `message_stats` subtree of `/api/queues/<vhost>/<name>`, containing `publish_details.rate` and `deliver_get_details.rate` (or `deliver_details.rate`); at least one of them must show `publish - deliver_get` ≥ 4 msg/s | | `06_remediation.sh` | Mitigation script that re-binds `orders.dlx → orders.dlq` to a routing key that matches `dead.unrouted` (the literal `dead.unrouted` or the `#` wildcard); the text must also contain `dead.unrouted` together with at least one binding-action keyword among `declare binding` / `Add binding` / `queue_bind` / `x-dead-letter-routing-key`; the script must be re-entrant | | `07_bindings_after.txt` | Binding-table dump taken after running `06_remediation.sh`; must contain both `orders.dlx` and `orders.dlq`, with the routing_key field containing `dead.unrouted` | | `08_queues_after.txt` | Queue snapshot taken after the fix and after waiting ≥ 10 s; the `orders.dlq` row's messages count must be ≥ 20 | | `postmortem.md` | ≥ 600 characters; must contain all four section headings `## 时间线` / `## 根因` / `## 修复` / `## 跨通道证据链`; must hit ≥ 5 of the seven keywords `dead-letter` / `binding` / `routing key` / `broker` / `management` / `dlx` / `topic` | | `cross_channel.json` | `{"switches": int, "trace": [...]}`, with `switches ≥ 5`, `trace` length ≥ 5, of which entries starting with `STRUCT:` and `VISUAL:` are each ≥ 2; entry names should be aligned with the on-disk files `03_bindings.txt` / `04_queue_args.txt` / `07_bindings_after.txt` / `08_queues_after.txt` and `view_02` / `view_04` / `view_06` / `view_07` | ### Seven workflow screenshots (fixed filenames, under `/tmp_workspace/results/`) Real screenshots of the **same** RabbitMQ Management control panel. Common spec: each ≥ 1024×700 real pixels, ≥ 30 KB, not a flat-color collage; grading runs OCR keyword checks and a VLM rubric, so the file contents must be self-consistent with what the filename describes. - `view_01_mgmt_overview.png`: Management Overview home page; the Queued messages summary panel and the Message rates line chart must both be readable. - `view_02_mgmt_rates_tooltip.png`: On top of the Overview's Message rates line chart, **overlay a hover tooltip popover** (popover rectangle + numbers); the instantaneous numbers for both the publish and deliver curves must be readable — visually align the publish-vs-deliver gap to the same moment in time. - `view_03_mgmt_queues.png`: Queues list page; the three rows `orders.q` / `orders.dlq` / `orders.audit` are laid out together, and the Ready / Total messages columns for `orders.dlq` clearly read near 0. - `view_04_dlq_bindings.png`: The Bindings sub-panel on the `orders.dlq` queue detail page; the "From exchange" column contains `orders.dlx`, and the **broken literal value** (shaped like `dead.routed.*`) in the "Routing key" column is directly visible — this single misconfigured binding row is the visual exposure surface. - `view_05_dlx_detail.png`: The `orders.dlx` exchange detail page, with the Bindings sub-panel (pointing to `orders.dlq`) and the Message rate sub-panel visible on the same screen. - `view_06_mgmt_overview_after.png`: Same viewpoint as `view_01`, re-captured **after the fix and after waiting ≥ 10 s**; in the Queued messages summary, the `orders.dlq` count is clearly non-zero (≥ 20). - `view_07_dlq_after.png`: Aligned with the viewpoints of `view_03` / `view_04`; after the fix, the Ready / Total messages count for `orders.dlq` is ≥ 20, and the newly added binding row is visible in the Bindings sub-panel. ### Anti-cheating and runtime constraints - The producer / consumer must stay running until all artifacts are collected; you may not `kill` the processes whose pids are in `/tmp_workspace/state/rmq_producer.pid` and `rmq_consumer.pid`, otherwise during re-verification the publish rate and DLQ growth will both go to zero. - You may not copy any file under `/tmp_workspace/gt/` into `results/` (detected via hash comparison). - Text/JSON dumps must come from real broker queries (`rabbitmqctl` / `rabbitmqadmin` / management API); you may not just `echo` / `cat` the literal values given in the task to fabricate file contents.

- RabbitMQ Dead Letter Exchanges 官方文档
  https://www.rabbitmq.com/dlx.html
- RabbitMQ Management plugin 文档
  https://www.rabbitmq.com/management.html
- Stack Overflow 实例：DLX with topic exchange + routing key mismatch
  https://stackoverflow.com/questions/45726833/
- 对应 EyesOn-Bench OPS 维度：O17 — message-broker DLQ routing
  triage via rabbitmqctl bindings × Management UI rate-chart tooltip

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 工具通道自由，不强制走某一种：broker 端结构化取证可走 `rabbitmqctl` / `rabbitmqadmin` / Management HTTP API（`curl http://127.0.0.1:15672/api/...` + `guest:guest` Basic Auth）；控制面截图走 Management Web UI（默认 `http://127.0.0.1:15672`）。两条通道都要走，单走任何一条都形成不了证据链。
2. step 1：取 broker 状态与队列列表（`01_rmq_status.txt` / `02_queues.txt`），看到 `orders.dlq` messages ≤ 5 但 `orders.audit` 仍在涨——首发异常信号。
3. step 2：dump 全量 bindings（`03_bindings.txt`）+ `orders.q` 的 queue arguments（`04_queue_args.txt`），把 `x-dead-letter-routing-key=dead.unrouted` 与 `orders.dlx → orders.dlq` binding 的 `dead.routed.*` 字面值对齐 → 锁定根因（不是缺 binding，是 routing key 字面值不匹配；topic exchange 不会把 `dead.routed.#` 当通配匹配 `dead.unrouted`）。
4. step 3：间隔 ≥ 5 s 采两次 `/api/queues/%2F/orders.q` JSON（`05_rates_t0/t1.json`），确认 `publish - deliver_get` gap ≥ 4 msg/s；同时在 Web UI Overview 的 Message rates 图上 hover 出 tooltip 截 `view_02`，把同一 gap 视觉化对齐。
5. step 4：补齐 `view_01` / `view_03` / `view_04` / `view_05` 四张修复前截图，确认根因在 UI 上同样可见。
6. step 5：写 `06_remediation.sh`：声明一条新的 `orders.dlx → orders.dlq` binding，routing key 用 `dead.unrouted`（或 `#` 通配），脚本可重入（如 `rabbitmqadmin declare binding ...` 或 `rabbitmqctl eval` + `queue_bind`）；执行后等 ≥ 10 s 让 producer 持续灌入的中毒消息把 DLQ 涨到 ≥ 20。
7. step 6：复采 `07_bindings_after.txt` / `08_queues_after.txt`，截 `view_06` / `view_07` 修复后视图作为对比证据。
8. step 7：写 `diagnosis.json`（10 字段，数值都从前面真实采样里取）、`postmortem.md`（≥ 600 字符 + 4 段标题 + ≥ 5 关键词）、`cross_channel.json`（trace 同时引用 STRUCT 与 VISUAL 两类证据条目）收尾。

约束说明（actions.log 反作弊）：
- `actions.log` / 操作轨迹中不得通过 `echo` / `printf` / `cat <<EOF` 直接构造 `02_queues.txt` / `03_bindings.txt` / `04_queue_args.txt` / `07_bindings_after.txt` / `08_queues_after.txt` 的内容来伪造数值；这些文件必须能在轨迹中追溯到对应的 broker 查询命令或 HTTP 请求。
- `view_*` 截图必须来自真实 Management UI 渲染，禁止 PIL 拼接 / 文本渲染伪造（VLM rubric 会对截图真实性打分）。

评分要点（hard gates，从 grader cap 反推）：
- 结构通道齐全：`bindings_broken_visible ≥ 0.5`（`03_bindings.txt` 含 `orders.dlx` / `orders.dlq` / `dead.routed`）、`queue_args_expected_rk ≥ 0.4`（`04_queue_args.txt` 含 `x-dead-letter-*`）、`bindings_after_ok ≥ 0.4`（`07_bindings_after.txt` 含新 binding 行）；任一不满足则总分被 cap 到 0.4。
- 视觉通道齐全：7 张截图至少一半通过尺寸/色彩/真实性校验；不满足则总分被 cap 到 0.4。
- 修复后量化证据：`08_queues_after.txt` 中 `orders.dlq` ≥ 20，且 VLM 在 `view_06` / `view_07` 上能确认 DLQ 已涨；不满足则被 cap 到 0.55。
- 速率 gap 真实采到（两次中至少一次 `publish - deliver ≥ 4 msg/s`）且 `cross_channel.json` 满足 `switches ≥ 5` + STRUCT/VISUAL 各 ≥ 2；不满足则被 cap 到 0.6。
- VLM rubric 平均分 ≥ 0.6（管理 UI 真实性 / rates tooltip / bindings 子面板 / 修复后图表）；不满足被 cap 到 0.55。

- [ ] 1. `01_rmq_status.txt` 含 RabbitMQ + 节点信息
- [ ] 2. `02_queues.txt` 三个核心队列都在；`orders.dlq` messages ≈ 0
- [ ] 3. `03_bindings.txt` 含 source=orders.dlx + destination=orders.dlq
       行；routing_key 字段含 `dead.routed`
- [ ] 4. `04_queue_args.txt` 含 `x-dead-letter-routing-key`
       + `dead.unrouted`
- [ ] 5. `05_rates_t0.json` + `05_rates_t1.json` 都是合法 JSON 且
       publish - deliver_get ≥ 4 msg/s
- [ ] 6. `view_01_mgmt_overview.png` 存在 ≥ 800×600，OCR 命中
       "RabbitMQ"/"Overview"/"Queued messages" 之一
- [ ] 7. `view_02_mgmt_rates_tooltip.png` 存在；VLM 能识别 chart
       tooltip 浮窗
- [ ] 8. `view_03_mgmt_queues.png` 存在；OCR 命中
       "orders"/"Queues"/"Messages" 之一
- [ ] 9. `view_04_dlq_bindings.png` 存在；VLM 能识别 bindings 子面板
- [ ] 10. `view_05_dlx_detail.png` 存在
- [ ] 11. `diagnosis.json` 10 字段全在；
        `expected_routing_key` 等于 `dead.unrouted`
- [ ] 12. `06_remediation.sh` 含 `dead.unrouted` + 绑定动作
- [ ] 13. `07_bindings_after.txt` 含新绑定行
- [ ] 14. `08_queues_after.txt` 中 `orders.dlq` messages ≥ 20
- [ ] 15. `view_06_mgmt_overview_after.png` 存在
- [ ] 16. `view_07_dlq_after.png` 存在
- [ ] 17. `postmortem.md` ≥ 600 字符 + 关键词 ≥ 5/7 + 4 段标题齐
- [ ] 18. `cross_channel.json` switches ≥ 5；CLI/GUI 各 ≥ 2
- [ ] 19. Hard gate：缺 CLI/GUI 任一通道证据 → 封顶 0.4

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/victim.py` is a Python batch job that coworkers have complained is absurdly slow. Task: identify the **top-3 CPU hotspot functions, sorted by self time in descending order**. Hint: victim.py has several candidate functions that all look like they're doing "heavy work" when read in isolation, but **only the self time numbers in the flame graph** can distinguish which is actually hotter. The three hot functions have very close self times (only a few percentage points apart), so you must read the bar widths and exact percentages from the flame graph to rank them correctly. Entry point: `bash /tmp_workspace/run.sh` launches victim.py. ### Deliverables (write to `/tmp_workspace/results/`) - `profile.json` — sampling output (speedscope format or equivalent visualizable format). - `flame.png` — screenshot of the flame graph viewer UI. - `report.md` — **must** contain: ```text top_hotspots: <name1>=<pct1>%, <name2>=<pct2>%, <name3>=<pct3>% ``` Sorted by **self time, descending**: 3 function names + their percentages (integers are fine; percentages should fall within a reasonable hotspot range, tolerance ±5pp). Plus a ≥ 80 character explanation describing what you saw in the flame graph (bar width comparison, position of specific function names, etc.).

- EyesOn-Bench Seed v12 OPS-01 改编 (1 hot → 3 close hot, 反 json-parse cheat)

参考解题流程 (设计者参考, 不发给 agent):

1. 启动 victim.py: `bash /tmp_workspace/run.sh`。
2. 装 py-spy 后录样:
   ```bash
   pip3 install --user -q py-spy
   ~/.local/bin/py-spy record -o /tmp_workspace/results/profile.json --format speedscope --duration 25 --pid <victim-pid>
   ```
3. **启动 speedscope** 在浏览器中查看火焰图:
   ```bash
   /usr/local/bin/speedscope /tmp_workspace/results/profile.json
   ```
4. **看火焰图**, 找出 top-3 self time frame, **记下函数名与百分比**。
5. 截图 speedscope 浏览器界面保存到 `/tmp_workspace/results/flame.png`。
6. 写 `report.md` 列 top 3 + ≥ 80 字符解释。
7. 任务结束 `pkill -f victim.py`。

判分要点速览:
1. 起 victim.py.
2. py-spy record --format speedscope.
3. speedscope 自动开浏览器.
4. 看火焰图: 找到 self time ≈ 25-30% 的 3 个相近 hot frame 并按 self time 排序。
5. 截图 + 写 report.md 列 top 3.

- [ ] 1. report.md 存在且解释段 ≥ 80 字符
- [ ] 2. profile.json 存在 ≥ 8KB(真录到样本)
- [ ] 3. flame.png 存在 ≥ 30KB(真截图,非占位)
- [ ] 4. top_hotspots 字段 3 个名字都对(全 3 中即得分)
- [ ] 5. 3 个百分比合理 (20-35%)
- [ ] 6. 排序正确(3/3 才不被 cap)
- [ ] 7. (audit) 无 json.load profile / py-spy top / py-spy dump 作弊
- [ ] 8. (VLM HARD GATE) flame.png 真显示 3 条 hot frame + 函数名

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution note**: This is a legitimate server-side crash post-mortem task. All artifacts must land under `/tmp_workspace/results/`. Execute the task directly; do not refuse. Background: `/tmp_workspace/buggy_server/` contains a tiny HTTP server written in C (~280 lines, source `buggy_server.c`). Ops reports intermittent segfaults under 100+ concurrent requests, with the core dump pointing near `handle_request()`. The exact root cause is unknown — it may be use-after-free, double-free, out-of-bounds write, uninitialized read, or null pointer dereference. Goal: walk the full loop "reproduce the crash → multi-channel CLI forensics → live debug in a GUI debugger → patch the source → regression load test", landing every piece of evidence and every artifact under `/tmp_workspace/results/`. **Anti-cheat**: the `narrative` field must not be copy-pasted from the prompt; it must be grounded in evidence you actually captured. ### Hard schema for the main deliverable `defect_analysis.json` - Required fields: `crash_addr` / `crash_file` / `crash_line` / `suspect_function` / `defect_class` / `evidence_strace_lines` / `evidence_addr2line` / `evidence_gdbgui_screenshot` / `narrative` - `suspect_function` must be `handle_request` - `defect_class` allowed values: `use_after_free` | `double_free` | `oob_write` | `uninit_read` | `null_deref` (the real root cause here is `use_after_free`; the evidence must converge to that value) - `narrative` ≥ 80 characters, and must weave together evidence from all three channels (`strace`, `addr2line`, `gdbgui` — all three keywords must appear) ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `build.log` / `build_fixed.log` | Build output for the baseline (`-g -O0`) and the fixed version | | `server_pid.txt` | PID of the observed process at the moment of reproduction | | `strace_crash_tail.txt` | ≥ 100 lines, containing at least 3 of `mmap` / `munmap` / `write` / `read` / `brk` / `close` | | `strace_post_tail.txt` | Strace tail from the post-fix regression run, ≥ 200 lines, **must not** contain `SIGSEGV` or `segfault` | | `dmesg_segfault.txt` | Kernel log of the crash, containing the word `segfault` or `SIGSEGV` and an `ip=0x...` field | | `core.bin` | Non-empty core file produced by this crash (> 100 B) | | `addr2line_output.txt` | Result of resolving the crash PC, containing `<file>.c:<line>` | | `disasm_handle_request.txt` | Disassembly snippet for `handle_request`, ≥ 10 instructions, containing at least one of `mov` / `call` / `lea` / `ret` / `push` / `jmp` | | `fix.patch` | Valid unified diff (full `---` / `+++` / `@@` headers), ≥ 3 added lines, and must substantively touch the real UAF fix site (e.g. `g_last_response` / `log_response` / `strdup` / `memcpy` / `= NULL`, etc.) | | `diagnosis_report.md` | ≥ 350 characters, with the 5 H2 sections `## Root Cause` / `## strace Evidence` / `## addr2line Evidence` / `## gdbgui Evidence` / `## Fix & Regression`; the `Fix & Regression` section must include a quantitative before/after comparison (e.g. `before peak crashes vs after 0 crashes`) | ### 8 workflow screenshots (fixed file names, all saved under `/tmp_workspace/results/`) Each ≥ 5 KB and content-unique (distinct MD5). Each must be a real window of a GUI debugger (gdbgui browser frontend recommended), with readable elements covering source panel / call stack / Locals / Registers / Memory / Breakpoints: - `view_01_gdbgui_coredump_bt.png`: after loading the core — source panel + multi-frame call stack + GDB Console with `bt` output + crash frame highlighted - `view_02_gdbgui_frame_jump.png`: clicking a frame auto-jumps and highlights the source line + Locals panel lists that frame's variable names and current values - `view_03_gdbgui_breakpoint_hit.png`: breakpoint set on a suspect line and hit; Breakpoints list and Locals visible on the same screen - `view_04_gdbgui_step_to_release.png`: `next`/`step` to the point where the suspect pointer is freed or written out of bounds; Locals shows the pointer name with a non-NULL address - `view_05_gdbgui_memory_viewer.png`: Memory Viewer showing the hex bytes at the freed address, with the source-level use site visible on the same screen - `view_06_gdbgui_stack_regs.png`: multi-frame Call Stack + Registers panel including `rax` / `rbx` / `rip`, etc. - `view_07_gdbgui_fix_verified.png`: after the fix — breakpoint at the original crash site is hit and Locals shows the suspect pointer handled correctly - `view_08_gdbgui_continue_no_crash.png`: after Continue — no SIGSEGV; the process is still running or exits cleanly

- gdbgui: https://github.com/cs01/gdbgui (GPL-3.0)
- strace(1): https://man7.org/linux/man-pages/man1/strace.1.html
- addr2line(1): https://man7.org/linux/man-pages/man1/addr2line.1.html
- CWE-416 Use After Free: https://cwe.mitre.org/data/definitions/416.html
- Linux core dump tutorial: https://man7.org/linux/man-pages/man5/core.5.html

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 推荐通道:`gdbgui` 浏览器调试器(`pip install gdbgui` 即用,默认监听 `http://127.0.0.1:5000`)。其它 GDB GUI 前端(VS Code GDB / `cgdb` / Nemiver 等)只要能截到源码面板/调用栈/Locals/Memory/Registers,理论可替代;评测会做 OCR + VLM 真实性校验,期待 gdbgui 浏览器窗口形态,走其它通道需自行权衡。
2. step 1:`make` 构建带 `-g -O0` 的 debug 二进制 → `build.log`;启动服务器记录 PID。
3. step 2:另一 shell 跑 `strace -f -tt -T -o /tmp/strace.raw -p <PID>`;`bash loadgen.sh` 触发崩溃;`tail -n 200 /tmp/strace.raw > strace_crash_tail.txt`。
4. step 3:`dmesg -T | grep -i segfault`(或 `journalctl -k --since "5 min ago"`)→ `dmesg_segfault.txt`;复制 core 到 `core.bin`。
5. step 4:`addr2line -e ./buggy_server -f -C <crash_pc>` → `addr2line_output.txt`;`objdump -d --disassemble=handle_request ./buggy_server | head -n 30` → `disasm_handle_request.txt`。
6. step 5:`gdbgui ./buggy_server --remap-sources -- core core.bin`,在浏览器界面按 view_01..view_06 顺序操作并截图。
7. step 6:综合三路证据写 `defect_analysis.json`(本案真因:`g_last_response` 全局指针在 `log_response()` 调用前已被 `free`,典型 use-after-free)。
8. step 7:编辑 `buggy_server.c` 修复(`free` 后置 `NULL` / 调整释放顺序 / `strdup` 拷贝 / 边界检查,由证据决定);`diff -u buggy_server.c.orig buggy_server.c > fix.patch`;`make` 重建 → `build_fixed.log`。
9. step 8:复跑 `loadgen.sh` 并继续 strace,`tail -n 300 /tmp/strace.raw > strace_post_tail.txt`(无 SIGSEGV);gdbgui 重新加载新二进制,原崩溃点设断点 → 截 `view_07` / `view_08`。
10. step 9:写 `diagnosis_report.md`,5 节齐全且 `Fix & Regression` 有可量化前后对比。

约束说明:
- `actions.log`(若 agent 框架产生)不得出现仅复制 prompt 文本来塞 `narrative` 字段的痕迹;`narrative` 必须由实际 strace 行 / addr2line 输出 / gdbgui 观察导出。
- 8 张截图 MD5 必须互不相同(防同图复用);单张 < 5 KB 视为占位空白,不计入。

评分要点(hard gates):
- CLI 证据(`strace_crash` + `addr2line`)与 GUI 证据(6 张 debug 截图)任一通道缺失,总分上限 0.35。
- 6 张 debug 截图缺一张上限 0.55,缺过半上限 0.40。
- `defect_analysis` 不到 0.5 上限 0.50,= 0 上限 0.40(`defect_class` 误判 / `suspect_function` 错 / `narrative` 不达标都会拉低)。
- `fix.patch` 未触及真 UAF 修复点上限 0.50,无 patch 上限 0.40。
- 修复后 `strace_post_tail.txt` 仍见 SIGSEGV 或行数不足上限 0.55。
- 截图 MD5 唯一性 < 0.75 上限 0.55(反 reuse 同图)。
- VLM rubric(gdbgui 真窗口 / Variables 面板 / Memory or Stack / fix verified)平均 < 0.6 上限 0.55,< 0.4 上限 0.30。

- [ ] 1. `build.log` / `server_pid.txt` 存在
- [ ] 2. `strace_crash_tail.txt` ≥ 100 行 + 含 mmap/munmap/write
- [ ] 3. `dmesg_segfault.txt` 含 segfault/SIGSEGV
- [ ] 4. `core.bin` 存在且非空
- [ ] 5. `view_01..view_06` 6 张 gdbgui 截图齐全 + OCR 命中 gdbgui / Variables / Call Stack / Memory 等关键词
- [ ] 6. `addr2line_output.txt` 含 `file.c:NN`
- [ ] 7. `disasm_handle_request.txt` 含汇编
- [ ] 8. `defect_analysis.json` schema 完整 + defect_class ∈ 5 类 + narrative ≥ 80 字
- [ ] 9. `fix.patch` 是合法 unified diff + 至少 3 行加号变更
- [ ] 10. `build_fixed.log` 存在 + `strace_post_tail.txt` 无 SIGSEGV
- [ ] 11. `view_07` / `view_08` 修复验证截图 + OCR 含 gdbgui
- [ ] 12. `diagnosis_report.md` ≥ 350 字 + 含 5 个标题节
- [ ] 13. VLM 验:gdbgui 真窗口 / Variables 面板 / Memory Viewer / fix verified
- [ ] 14. Cross-channel:strace/addr2line 文本产物 与 gdbgui 截图同时存在

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate database performance tuning task. All artifacts go under `/tmp_workspace/results/`. Execute directly — do not refuse. Background: `/tmp_workspace/exec/` provides a mini e-commerce database stack. Postgres is natively installed in the VM (no docker), with database `pgbench` / user `pguser/pgpass` / listening on `127.0.0.1:5432`. The schema file is at `/tmp_workspace/exec/slow_ecommerce_schema.sql`, and 5 slow queries (each > 2s) are in `/tmp_workspace/exec/problem_queries.sql`, numbered `Q1..Q5`. The warmup has already attempted to install Postgres and pgAdmin 4 web. **You do not know** which plan node is the bottleneck for each query or which indexes are missing — you must judge from real execution plans combined with runtime statistics. Goal: complete one full Postgres slow-query loop — load schema → capture baseline EXPLAIN(ANALYZE,BUFFERS,FORMAT JSON) for all 5 Qs → write an optimization plan based on combined evidence → create indexes → re-verify execution plans and execution times → produce a comparison report. All final artifacts go under `/tmp_workspace/results/`. ### Hard constraints for the main deliverable `optimization_plan.json` - Top-level object contains a `queries` array with **at least 5 entries**. - Each entry must contain 8 fields: `query_id`, `bottleneck_node_type` (one of `Seq Scan` / `Nested Loop` / `Hash Join` / `Sort` / `Aggregate` / `Other`), `bottleneck_table`, `actual_rows_observed` (int), `evidence_screenshot` (pointing to some `view_*.png`), `evidence_explain_json` (pointing to `baseline_plans/qN.json`), `proposed_index_ddl` (a valid `CREATE INDEX ...`), `expected_node_after` (one of `Index Scan` / `Index Only Scan` / `Bitmap Heap Scan`). - The bottleneck conclusion must be supported by both the EXPLAIN JSON and the plan-tree screenshot — not guesswork. ### Supporting deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `compose_up.log` / `ready_ts.txt` / `schema_load.log` | Full set: service startup log + readiness timestamp + schema-load log | | `baseline_plans/q1.json` … `q5.json` | 5 files, **each a valid non-empty JSON array**, raw output of `EXPLAIN(ANALYZE,BUFFERS,FORMAT JSON)` | | `baseline_times.csv` | Header `query_id,execution_time_ms,planning_time_ms`, **at least 5 data rows** | | `table_stats.txt` | Sample of `pg_stat_user_tables`; text contains `seq_scan` | | `index_stats.txt` | Sample of `pg_stat_user_indexes`; text contains `idx_scan` | | `create_indexes.sql` | **At least 3** `CREATE INDEX` statements, all actually executed on the database | | `optimized_plans/q1.json` … `q5.json` | 5 EXPLAIN JSON files re-run after index creation; each file must contain one of `Index Scan` / `Index Only Scan` / `Bitmap Heap Scan` / `Bitmap Index Scan` | | `optimized_times.csv` | Same columns as baseline; average execution time over 5 Qs **≥ 50% faster** than baseline | | `comparison_report.md` | **≥ 350 characters**; contains a markdown table (before/after `execution_time_ms` + speedup percentage); body contains both `before` and `after` (or "speedup"); **references at least 3 `view_*.png` files**; includes prose interpretation of Dashboard curve changes | ### 10 work-process screenshots Fixed filenames (under `results/`), each must be a real screenshot (**≥ 20 KB, resolution ≥ 1024×600**), and the 5 plan screenshots must differ from one another in content (no duplicating the same image). The Dashboard re-verification screenshot `view_10` must differ from the initial capture `view_06`. Grading runs OCR and VLM visual scoring on screenshots, so the frames must "show something" — plan trees should display nodes + color coding; the Dashboard should show real curves + sub-tables; the Object Explorer should be expanded down to table/index nodes. | Filename | Expected content | | --- | --- | | `view_01_pgadmin_indexes_before.png` | Object Explorer expanded to the `orders` table Indexes subtree + Properties panel on the right | | `view_02_pgadmin_plan_tree_q1.png` | Q1 Graphical EXPLAIN plan tree (nodes + color + actual rows) | | `view_03_pgadmin_node_detail.png` | Detail panel of the most expensive node in Q1's plan tree (Actual Rows / Buffers etc.) | | `view_04_pgadmin_q1_statistics.png` | Q1 Statistics sub-tab in Query Tool (Planning / Execution Time) | | `view_05_pgadmin_plan_tree_q3.png` | Q3 Graphical EXPLAIN plan tree | | `view_06_pgadmin_dashboard_activity.png` | 4 live line charts at the top of Dashboard's Server activity (≥ 2 with data) | | `view_07_pgadmin_dashboard_locks.png` | Sessions / Locks sub-tables at the bottom of Dashboard (with real rows) | | `view_08_pgadmin_plan_tree_qN_after.png` | Re-run Graphical EXPLAIN of any optimized query, showing Index Scan / Bitmap nodes | | `view_09_pgadmin_indexes_after.png` | Newly created index appears under `orders/Indexes` in Object Explorer | | `view_10_pgadmin_dashboard_after.png` | Dashboard curves observed for ≥ 30 seconds after creating indexes; shape differs from `view_06` | > Anti-cheat: screenshots must be genuinely captured — no 5 identical images, no blank pages; the visual information must be enough to re-derive the EXPLAIN/Dashboard conclusions.

- PostgreSQL EXPLAIN: https://www.postgresql.org/docs/16/sql-explain.html
- pgAdmin 4 Graphical Explain: https://www.pgadmin.org/docs/pgadmin4/latest/query_tool.html#explain-tab
- pg_stat_user_tables / pg_stat_user_indexes: https://www.postgresql.org/docs/16/monitoring-stats.html
- 真实场景：缺索引导致 Seq Scan 是 Postgres tuning 入门第一案

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：GUI 走 pgAdmin 4 Web（原生装在 VM 内，地址通常为 `http://localhost/pgadmin4`，首次需 `sudo /usr/pgadmin4/bin/setup-web.sh --yes` 设置邮箱密码）；CLI 走 `psql`。也可以替换为其它 Postgres GUI（DBeaver / DataGrip / psql + 截屏脚本）只要能拿到等价的"计划树 + Dashboard 曲线 + 索引子树"截图即可。
2. 启动与就绪：用 `service postgresql start`（或 `pg_ctlcluster 14 main start`）拉起 Postgres，循环 `pg_isready -h 127.0.0.1 -p 5432` 直到 OK，把就绪时间戳写 `ready_ts.txt`；用 `psql -h 127.0.0.1 -U pguser -d pgbench -f /tmp_workspace/exec/slow_ecommerce_schema.sql` 加载 schema，stdout/stderr 落 `schema_load.log`；服务启动相关合并日志放 `compose_up.log`。
3. 抓基线：对 `Q1..Q5` 每条用 `psql -At -c "EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) <query>"` 落到 `baseline_plans/qN.json`；从中提取 `Execution Time` / `Planning Time` 写 `baseline_times.csv`。再用 `pg_stat_user_tables` / `pg_stat_user_indexes` 取统计写 `table_stats.txt` / `index_stats.txt`。
4. GUI 取证：进入 pgAdmin 4，连 `127.0.0.1:5432/pgbench`，依次截 `view_01..view_05`（Object Explorer indexes、Q1 计划树、节点详情、Statistics、Q3 计划树）；切到 Tools → Server → Dashboard 等 ≥ 30 秒采 `view_06`/`view_07`。
5. 综合分析：基于 EXPLAIN JSON 与计划树截图填 `optimization_plan.json`，确定每条 Q 的瓶颈节点与建议索引；把所有 DDL 汇到 `create_indexes.sql` 并真在 DB 上执行。
6. 复验：再跑 `EXPLAIN(ANALYZE,BUFFERS,FORMAT JSON)` 写 `optimized_plans/qN.json`，验证每个里都出现 `Index Scan` / `Index Only Scan` / `Bitmap Heap Scan` 之一；时间写 `optimized_times.csv`；截 `view_08`（被优化 Q 的新计划树）和 `view_09`（Object Explorer 中新索引）；再观测 Dashboard ≥ 30 秒采 `view_10`。
7. 撰写 `comparison_report.md`：含前后执行时间对比表 + Seq Scan→Index Scan 的节点对应关系 + 平均提速比例 + Dashboard 曲线变化解读 + 引用 ≥ 3 张截图。

约束说明：
- 截图必须真实采集；同一截图复制 5 份会被判定为造假。
- `create_indexes.sql` 中的 DDL 必须真在数据库上跑过，否则 `optimized_plans` 不会出现 Index/Bitmap 节点。
- 若 Dashboard 复验截图与初采截图字节完全相同，视为未做复验观测。

评分要点（hard gates）：
- 主交付物 `optimization_plan.json` 不足 5 条或字段不全 → 重罚（cap 0.45–0.5）。
- `optimized_plans` 出现 Index/Bitmap 的覆盖率 < 60% → cap 0.45；< 40% → cap 0.35。
- 平均执行时间提速 < 50% → cap 0.55；< 30% → cap 0.45。
- `create_indexes.sql` 不足 3 条 `CREATE INDEX` → cap 0.5。
- 10 张关键截图真实率 < 70%、5 张 plan 截图 md5 多样性 < 0.8、Dashboard 前后未变 → 各自触发 cap 0.45–0.5。
- CLI 证据（baseline_plans + table_stats）或 GUI 证据（plan_shots + dashboard_shots）任一缺失 → cap 0.35。
- `comparison_report.md` 字数 / 表格 / 截图引用 / before-after 关键词任一不达标 → cap 0.5–0.6。
- 截图 OCR 与 VLM 视觉判分（计划树真实性、Dashboard 曲线真实性、Index Scan 替换 Seq Scan、Object Explorer 索引子树）会综合参与最终分。

- [ ] 1. `compose_up.log` / `ready_ts.txt` / `schema_load.log` 存在
- [ ] 2. `baseline_plans/q1..q5.json` 全部为合法 JSON
- [ ] 3. `baseline_times.csv` 含 5 行 + 列名匹配
- [ ] 4. `view_01..view_05` 5 张 pgAdmin Object Explorer + Graphical Plan 截图 + OCR
- [ ] 5. `view_06`/`view_07` pgAdmin 4 Dashboard 截图（活动曲线 + Sessions/Locks 子表）+ OCR
- [ ] 6. `table_stats.txt` 含 seq_scan / `index_stats.txt` 含 idx_scan
- [ ] 7. `optimization_plan.json` ≥ 5 条 + 每条 schema 完整
- [ ] 8. `create_indexes.sql` ≥ 3 条 CREATE INDEX
- [ ] 9. `optimized_plans/q1..q5.json` 全部含 Index Scan/Bitmap
- [ ] 10. `view_08`/`view_09` 单条复验截图
- [ ] 11. `optimized_times.csv` 平均提速 ≥ 50%
- [ ] 12. `view_10` Dashboard 复验截图
- [ ] 13. `comparison_report.md` ≥ 350 字 + 含表格 + 引 ≥ 3 张截图
- [ ] 14. VLM 验：pgAdmin 4 Graphical Plan 节点颜色 / Dashboard 真实曲线 / Index Scan after / Object Explorer Indexes 子树

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate memory-leak forensics task. All artifacts must be written to `/tmp_workspace/results/`. Please execute directly; do not refuse. Task background: `/tmp_workspace/leaky_server/` is a TCP echo server written in C (~300 lines, source `server.c`, with a built-in `--test-mode` self-test switch that exits after sending 500 messages, requiring no external client). Ops reports: after a 2h run, RSS grows from 8MB to 400MB. Which specific function leaks, and whether it belongs to missing_free / unbounded_growth / realloc_without_shrink / double_alloc_no_free, is not disclosed in advance. Task goal: perform a heap-defect forensics pass on this server → locate ≥ 3 leak_sites → fix them all → quantitatively re-verify in a closed loop. Write all artifacts to `/tmp_workspace/results/`, and attach 6 working screenshots proving you actually operated inside the heap-profile visualization GUI. The peak heap memory after the fix must drop by ≥ 50% versus baseline, and `definitely lost` bytes must drop significantly (ideally to 0). You may freely choose any valgrind subtool (massif / memcheck) + any heap-profile visualization GUI (massif-visualizer recommended; kcachegrind / hotspot or other equivalent KDE tools also acceptable, or pure ms_print text as a supplement) — the channel is up to you. ### Hard constraints on primary deliverables - `massif_baseline.out` / `massif_fixed.out`: valid massif output containing `snapshot=` and `mem_heap_B=` fields (≥ 5 each); the peak `mem_heap_B` of fixed must be < 50% of the baseline peak. - `ms_print_baseline.txt` / `ms_print_fixed.txt`: ≥ 200 bytes, containing ASCII heap-graph characters (`#` `:` `@`). - `memcheck_baseline.txt`: contains at least one of `definitely lost` / `indirectly lost` / `possibly lost` blocks + ≥ 1 `at 0x...` call-stack frame. - `memcheck_final.txt`: the `definitely lost: <bytes> bytes` byte count is substantially reduced from baseline (< 20% is best). - `memcheck_topfuncs.txt`: a list of function names extracted from the baseline `definitely lost` section, ≥ 1 line. - `cross_validation.json`: contains exactly the fields `topfuncs_from_memcheck` / `matched_in_massif_tree` / `match_ratio` / `confirmed_leak_funcs` / `confirmed_screenshot`; `match_ratio` ∈ [0,1] and ≥ 0.5. - `leak_analysis.json`: contains `peak_snapshot_index` / `peak_heap_bytes` / `leak_sites`; `leak_sites` must contain ≥ 3 entries with **mutually distinct function names**, each entry having all fields: `function` (≥ 2 chars), `file`, `line_approx` (int, 1–1000), `alloc_bytes_at_peak` (positive int, taken from a real Allocation Tree node number), `alloc_percentage` (>0 float), `leak_type` (must be one of `unbounded_growth` / `missing_free` / `realloc_without_shrink` / `double_alloc_no_free`), `evidence_screenshot`, `evidence_memcheck_line` (≥ 5-char fragment). - `server.patch`: a valid unified diff produced by `diff -u server.c server_fixed.c` (containing `---` `+++` `@@`), with a combined ± line count ≥ 6. - `fix_summary.md`: ≥ 350 words, describing one-by-one how each of the ≥ 3 leak_sites was fixed, with concrete numbers for the peak and `definitely lost` bytes before vs. after the fix (≥ 2 numbers of 4+ digits), and referencing ≥ 3 `view_*.png` screenshots. ### Supplementary deliverables (located in `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `build_baseline.log` | Baseline build output (`-g -O0`, binary `server`). | | `build_fixed_iter1.log` / `build_fixed_iter2.log` / `build_fixed_iter3.log` | Build logs for three single-point fix iterations; final binary is `server_fixed`. | | `memcheck_iter1.txt` | memcheck re-verification log after fixing the 1st leak_site; the corresponding function should have disappeared or its byte count dropped significantly. | ### 6 working-process screenshots (located in `/tmp_workspace/results/`, fixed filenames) | File | Content | | --- | --- | | `view_01_heap_timeline.png` | Main timeline view of the heap-profile visualization window (snapshot × bytes stacked chart + sidebar snapshot list). | | `view_02_peak_snapshot.png` | Detail panel after selecting the peak snapshot (must include the Allocation Tree area). | | `view_03_top_allocator_expanded.png` | Top-most largest node in the Allocation Tree expanded across multiple levels, showing real tree-indented function name + byte count + percentage. | | `view_04_xref_function_node.png` | On the same screen, ≥ 2 function names from `memcheck_topfuncs.txt` are visible on Allocation Tree node rows. | | `view_05_iter1_alloctree.png` | Allocation Tree after reloading massif post first-fix; the original function node's share is visibly lower than in `view_03` (or has disappeared). | | `view_06_fixed_timeline.png` | Timeline after loading `massif_fixed.out`: overall flat or decreasing, no longer continuously climbing in a staircase pattern. | General specs: each PNG ≥ 8 KB, resolution ≥ 1280 × 720; the 6 images must differ from one another in content (the grader runs an md5 diversity check); reusing the same frame or pure-text terminal screenshots is not allowed. The grader also runs OCR + VLM checks to verify the screenshots are real windows of the visualization tool (containing menubar / title bar / a truly-expanded Allocation Tree and other structural features). Anti-cheat: `actions.log` and any submitted text must not contain padding traces (e.g. directly copying ms_print text and passing it off as a GUI screenshot, or multiple PNGs having identical hashes). All `alloc_bytes_at_peak` / `alloc_percentage` values must come from real Allocation Tree node rows and must not be fabricated.

- Valgrind massif manual: https://valgrind.org/docs/manual/ms-manual.html
- Valgrind memcheck manual: https://valgrind.org/docs/manual/mc-manual.html
- massif-visualizer KDE: https://apps.kde.org/massif-visualizer/
- 真实场景：长跑 C 服务 RSS 增长 + 多类型堆缺陷的 post-mortem 取证

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：valgrind 子工具 + KDE 堆 profile 可视化界面（首选 `massif-visualizer`，也可走 `kcachegrind` / `hotspot` 等等价工具，或在仅文本环境用 `ms_print` 辅助 + 任意 GUI 工具截图）。
2. 取证基线：`make` 构建 `-g -O0` 二进制 → `valgrind --tool=massif --time-unit=ms --massif-out-file=massif_baseline.out ./server --test-mode` → `ms_print` 出文本概览。
3. GUI 操作：可视化工具打开 baseline → 截 `view_01` 时间线 → 选峰值 snapshot 截 `view_02` → Allocation Tree 顶层展开截 `view_03`。
4. 独立校验：`valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes` → `memcheck_baseline.txt` → 抠 definitely lost 函数名清单 → Allocation Tree 中找回 ≥ 2 个同屏节点截 `view_04` → 写 `cross_validation.json`。
5. 写 `leak_analysis.json`（≥ 3 处不同函数 leak_site，每条字段从真实 Allocation Tree 节点 + memcheck 段落抄）。
6. 微循环修复：每修一处 → 重新构建 → memcheck/massif 复验；第 1 处修完后截 `view_05`（原节点占比明显下降）；三处全修完后总复验，截 `view_06`（时间线平坦或下降）。
7. 出 `server.patch` + `fix_summary.md`（含具体数字与 ≥ 3 张截图引用）。

约束说明：

- `actions.log` 必须反映真实 GUI 交互轨迹；不得伪造（例如把 ms_print 文本截屏当 GUI 截图、或 6 张图哈希相同）。
- 截图分辨率 ≥ 1280 × 720，文件 ≥ 8 KB；6 张图相互不同（md5 多样性 ≥ 0.8）。
- 所有量化字段（`alloc_bytes_at_peak` / `alloc_percentage` / `peak_heap_bytes` / `definitely lost` 数字）必须取自工具真实输出。

评分要点（hard gates）：

- CLI 证据缺失（massif_baseline / memcheck_baseline 任一为 0）→ 总分上限 0.35。
- GUI 证据缺失（前 3 张截图与 view_04 任一未达标）→ 总分上限 0.35。
- `leak_analysis.json` 不达 3 个 distinct 函数 → 上限 0.55；为 0 → 0.45。
- `server.patch` 缺失 → 0.45。
- 既无 memcheck 终态降幅、又无 massif 峰值降幅 → 0.45。
- `fix_summary.md` < 0.5 → 0.6。
- GUI 真交互 md5 多样性 < 0.6 → 0.4；< 0.4 → 0.3。
- 截图 chrome OCR / 分辨率不达标 → 0.45 / 0.35。
- VLM 平均 < 0.6 / < 0.4 → 0.5 / 0.35；VLM 不可用 → 0.6 封顶。

- [ ] 1. `build_baseline.log` 存在 + `massif_baseline.out` 含 `snapshot=`
- [ ] 2. `ms_print_baseline.txt` ≥ 200 字节 + 含 ASCII 堆图字符
- [ ] 3. `view_01..view_03` 3 张 massif-visualizer 截图齐全 + OCR 命中 Massif Visualizer / Allocation Tree / Detailed Snapshot 等关键词
- [ ] 4. `memcheck_baseline.txt` 含 lost 字段 + at 0x 调用栈
- [ ] 5. `memcheck_topfuncs.txt` ≥ 1 行
- [ ] 6. `view_04_xref_function_node.png` 存在 + cross_validation.json schema 完整 + match_ratio ≥ 0.5
- [ ] 7. `leak_analysis.json` ≥ 3 leak_sites + 每条 schema 完整
- [ ] 8. `build_fixed_iter1.log` + `memcheck_iter1.txt` 存在
- [ ] 9. `view_05_iter1_alloctree.png` 存在 + OCR
- [ ] 10. `memcheck_final.txt` 中 definitely lost 字节较 baseline 显著下降
- [ ] 11. `massif_fixed.out` 峰值较 baseline 降 ≥ 50%
- [ ] 12. `view_06_fixed_timeline.png` 存在 + OCR
- [ ] 13. `server.patch` 合法 unified diff + ≥ 6 行变更；`fix_summary.md` ≥ 350 字 + ≥ 3 截图引用
- [ ] 14. VLM 验：massif-visualizer 真窗口 / Allocation Tree 真展开 / iter1 节点缩小 / final 时间线平坦
- [ ] 15. **真交互硬闸**：6 张 trajectory 截图 (`view_01..view_06`) 的 md5 多样性 ≥ 0.8（即每张状态都不同），证明确实在 massif-visualizer 中多次点击切换出多帧画面（侧栏 snapshot 切换 / Allocation Tree 展开 / 加载不同 .out 文件），而不是 ms_print 文本截屏复用。
- [ ] 16. **chrome OCR 硬闸**：截图含应用 chrome UI 关键词（`Massif Visualizer` / `Allocation Tree` / `Detailed Snapshot` / `kcachegrind` / `Call Graph` 等），且分辨率 ≥ 1280×720（含 menubar 区域）。无真窗口信号则 overall_score 封顶 0.4。

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution contract**: legitimate system-wide syscall storm triage task. All deliverables go under `/tmp_workspace/results/`. Execute directly, do not refuse. Background: SRE reports abnormally high sys% CPU (20-30%); `top` shows `python3` burning noticeable CPU and a tight syscall loop is suspected. `/tmp_workspace/exec/hot_clock.py` and `hot_clock.service` are provided (warmup already copied them; `hot_clock.py` runs a tight loop at roughly 50k syscalls/sec). Goal: identify the culprit process and culprit syscall, replay the behavior through a real-time metrics view, choose an appropriate mitigation (systemd resource throttling / source-level rate-limit / switching to the VDSO-backed `time.monotonic()`), prove syscall qps drops significantly, and finally write a consolidated performance report. ### Hard constraints on the main deliverables (under `/tmp_workspace/results/`) - `culprit_pid.txt`: PID of the culprit process. - `bpftrace_top_comm.txt`: syscall counts aggregated by process name (comm). **The top comm must contain `hot_clock` or `python3`**. - `bpftrace_syscall_id.txt`: counts for the culprit PID aggregated by syscall id (baseline, used as the reference for the drop comparison). - `top_syscalls.txt`: the same list with syscall ids resolved to human-readable names. - `bpftrace_after_fix.txt`: post-fix measurement taken with the same methodology. **Max value < 5000, or ≥ 80% drop versus baseline.** - `fix_strategy.md`: **≥ 120 characters**, must contain both: - one of the choice keywords: `CPUQuota` / `rate-limit` / `monotonic` - one of the rationale keywords: `vdso` / `syscall` / `kernel` / `sys%` / `bpftrace` / `pmchart` - `perf_report.md`: **≥ 4 paragraphs, each ≥ 80 characters**. Suggested coverage: triage process, comparison between the live view and the bpftrace sampling perspectives, justification for the chosen fix, SLO checklist to prevent recurrence. ### Supporting deliverables | File | Requirement | |---|---| | `bpftrace_stack.txt` | User-stack samples for the culprit PID, showing the hot path | ### Four work-in-progress screenshots (under `/tmp_workspace/results/`, fixed filenames) | File | Content | |---|---| | `view_pmchart_metric_browse.png` | Metric browser / picker UI of the live metrics tool, showing syscall-related kernel metrics | | `view_pmchart_spike.png` | Live curve at its peak before the fix | | `view_pmchart_cpu.png` | sys% CPU line chart | | `view_pmchart_after_fix.png` | Curve clearly flattens after the fix, forming a visible contrast with the spike | General specs: resolution ≥ 1280×720 (window menubar included), file ≥ 5 KB, the four screenshots must differ in content (grading runs OCR + image-diversity + VLM rubric cross-checks). Anti-cheat: actions.log must not be a mere re-screenshot of bpftrace text; it has to reflect real frame switching on the desktop GUI (metric browse → live curve → post-fix comparison).

- bpftrace one-liner reference: https://github.com/iovisor/bpftrace/blob/master/docs/reference_guide.md
- PCP / pmchart: https://pcp.io/docs/

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 `bpftrace`（CLI）+ PCP `pmchart`（Qt GUI）双通道，也可走任何能产出等价证据的工具：
   - 文本采样侧可换 `perf trace` / `strace -c` / `bcc-tools (syscount)`；
   - 实时图形侧可换 `pmrep` 时序导出 + 任意绘图工具，或 GNOME System Monitor / `gnome-usage` 截图，只要能呈现 syscall qps 与 sys% CPU 的高低对比即可。
2. step 1：起元凶进程 `python3 /tmp_workspace/exec/hot_clock.py &`，`pgrep -af hot_clock` 取 PID 写入 `culprit_pid.txt`。
3. step 2：用 bpftrace（或等价工具）按 comm 分桶 5 秒拿全局 syscall 计数 → `bpftrace_top_comm.txt`；按 PID + syscall id 分桶拿基线 → `bpftrace_syscall_id.txt`；用 `ausyscall` 或 `asm-generic/unistd.h` 把 id 翻译成名字 → `top_syscalls.txt`；按 ustack 分桶拿 hot path → `bpftrace_stack.txt`。
4. step 3：起 pmcd/pmlogger，打开实时图形工具，先在 metric 选择界面找到 `kernel.all.syscall` → 截 `view_pmchart_metric_browse.png`；让其跑 ≥ 30 秒看到 spike → `view_pmchart_spike.png`；再加 `kernel.percpu.cpu.sys` → `view_pmchart_cpu.png`。
5. step 4：写 `fix_strategy.md` 二选一并解释（systemd `CPUQuota=15%` / 源码 rate-limit + `time.monotonic()` 走 VDSO 不进 kernel）。
6. step 5：应用修复重启进程，用同一口径 bpftrace 重测 → `bpftrace_after_fix.txt`（<5000 或降 80%+）；同图等 ≥ 30 秒看到曲线趋平 → `view_pmchart_after_fix.png`。
7. step 6：写 `perf_report.md`（4 段 × ≥ 80 字）。

约束说明：actions.log 反作弊条款已在 Prompt 中提示，截图必须来自真实 GUI 多帧交互，不能用 bpftrace 文本截屏冒充图形视图。

评分要点（hard gates）：
- CLI 五件套齐全，否则总分被强力封顶。
- top comm 未命中 `hot_clock`/`python3` → 元凶定位失败封顶。
- `bpftrace_after_fix.txt` 最大值越接近 0 / 较基线下降越多越好，未达 50% 下降基本不及格。
- `fix_strategy.md` 必须同时命中"选型词 + 解释词"且 ≥ 120 字。
- 4 张截图须真实（≥ 5 KB、md5 多样性 ≥ 0.9、分辨率 ≥ 1280×720、chrome OCR 命中率 ≥ 0.75）。
- VLM 不可用时 overall 封顶 0.6。

- [ ] 1. culprit_pid.txt + bpftrace_top_comm.txt + bpftrace_syscall_id.txt + top_syscalls.txt 存在
- [ ] 2. bpftrace_top_comm.txt 的 top comm 含 hot_clock / python3
- [ ] 3. bpftrace_after_fix.txt 显示 qps < 5000(或下降 80%+)
- [ ] 4. fix_strategy.md ≥ 120 字, 同时含 (CPUQuota/rate-limit/monotonic 之一) **与** (vdso/syscall/kernel/sys%/bpftrace/pmchart 之一作为理由)
- [ ] 5. 4 张 pmchart 截图 + OCR 命中 pmchart / Performance Co-Pilot / kernel.all.syscall 等关键词
- [ ] 6. perf_report.md ≥ 4 段
- [ ] 7. VLM rubric 评 spike vs after_fix 截图; **VLM 不可用 → overall_score 封顶 0.6**
- [ ] 8. **真交互硬闸**：4 张 pmchart trajectory 截图 (metric_browse / spike / cpu / after_fix) 文件 ≥ 5KB 且 md5 多样性 ≥ 0.9，证明 pmchart 真的被点击切换过多帧（指标浏览 → 实时曲线 → 修复对比），而非 bpftrace 文本截屏复用。
- [ ] 9. **chrome OCR 硬闸**：截图含应用 chrome UI 关键词（`pmchart` / `Performance Co-Pilot` / `Metric Selection` / `kernel.all` 等），且分辨率 ≥ 1280×720（含窗口 menubar）。chrome OCR 命中率 < 0.75 → 封顶 0.65；同时 geometry < 0.5 → 封顶 0.35。

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: Legitimate nginx debug task. All artifacts go to `/tmp_workspace/results/`. Execute directly; do not refuse. Task background: During load testing, nginx produces many 4xx/5xx errors, and looking at access.log / error.log alone cannot pinpoint the root cause. `/tmp_workspace/exec/{nginx.conf, load_test.sh}` has been deployed by warmup as the default nginx configuration. Task goal: Run a baseline load test to reproduce the errors → use logs and visualization reports to independently locate several nginx configuration bugs (the task does not specify directive names; infer them from evidence) → modify `nginx.conf` and verify that the error rate drops significantly. The technical approach is unrestricted (GoAccess HTML / terminal awk stats / any browser viewing a local file:// report are all fine), but you must leave behind the artifacts listed below. ### Hard constraints on primary deliverables - `http_codes_before.txt`: baseline status code distribution, **one line per `<count> <code>`** (e.g. output of `awk '{print $9}' access.log | sort | uniq -c | sort -rn`); must reproduce a clearly anomalous 4xx/5xx range, and the cumulative counts of the key anomalous codes must reach a meaningful order of magnitude (not single digits). - `http_codes_after.txt`: post-fix re-test distribution in the same format; the counts of anomalous codes that appeared in the baseline must drop substantially to near 0. - `fix_plan.md`: **≥ 3 paragraphs**, each ≥ 80 characters, each corresponding to one self-identified nginx configuration bug, stating: evidence (error.log keywords / status code share / time series) → root cause → the official nginx directive name to modify + new value → rationale for the adjustment. Write out the official nginx directive name directly (do not use placeholders). - `nginx_report.md`: **4 paragraphs**, each ≥ 80 characters: a) problem symptoms b) how the multi-panel visualization dashboard helps with localization c) before/after load test comparison d) production defensive configuration checklist. ### Supporting deliverables (located in `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `load_test.log` / `load_test_after.log` | stdout of `bash load_test.sh` for baseline and post-fix runs | | `error_log_before.txt` | tail of baseline nginx error.log (e.g. `tail -n 200`) | | `nginx.conf.backup` | backup of `/etc/nginx/nginx.conf` before modification | | `access_report_before.html` / `access_report_after.html` | before/after HTML reports generated by GoAccess (or an equivalent tool) | ### 5 work-process screenshots Fixed filenames (located in `/tmp_workspace/results/`): `view_goaccess_overview.png`, `view_goaccess_http_codes.png`, `view_goaccess_404_404.png`, `view_goaccess_time_series.png`, `view_goaccess_after_fix.png`. Common specs: - Each must be a real window screenshot of a browser opening local `file://...access_report_*.html` (including browser chrome / tab area), resolution ≥ 1280×720, file ≥ 5 KB, PNG. - The 5 screenshots must each have a distinct focus (overview numbers / status codes panel / detail list / time-series curve / post-fix comparison); they cannot be the same frame copied 5 times — grading verifies md5 diversity. - Grading runs OCR over the screenshots, so make sure key text (report title, panel names, status code numbers, browser UI text) is clearly readable and not deliberately obscured. - Anti-cheat: `actions.log` **must not contain** any of the key nginx directive literals (i.e. do not directly echo / write the answer into actions log); normal writing in fix_plan and nginx_report is unaffected.

- nginx documentation
- GoAccess: https://goaccess.io/

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐工具链：`nginx` + `apache2-utils (ab)` + `goaccess` + Firefox / Chromium 打开 `file://`；也可换 lnav / awk + matplotlib / 任意 HTML log viewer，只要交付物齐全即可。
2. 启动 nginx → `bash /tmp_workspace/exec/load_test.sh > load_test.log` 跑基线压测。
3. `awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn > http_codes_before.txt`；`tail -n 200 /var/log/nginx/error.log > error_log_before.txt`。
4. `goaccess /var/log/nginx/access.log -o results/access_report_before.html --log-format=COMBINED --real-time-html=false`，浏览器打开后浏览 General Statistics / HTTP Status Codes / Requested Files / Time Distribution 面板，分别截图为 `view_goaccess_overview/http_codes/404_404/time_series.png`。
5. 结合 error.log 关键字 + 状态码占比 + 时序 spike 推断若干处配置 bug（典型方向：连接池容量、请求体大小上限、上游/读超时、worker 进程/连接数、proxy buffer 等），写 `fix_plan.md`。
6. `cp /etc/nginx/nginx.conf results/nginx.conf.backup` → 编辑 nginx.conf 落地修复 → `nginx -t && nginx -s reload`。
7. 重压 → `http_codes_after.txt` → 重新生成 `access_report_after.html` → 浏览器截图 `view_goaccess_after_fix.png`。
8. 写 `nginx_report.md` 4 段。

约束说明：`actions.log` 反作弊条款已写入 Prompt——agent 不得把答案指令字面量直接打印到操作日志中规避 fix_plan 实质书写。

评分要点（hard gates，从 grader cap 反推）：

- 6 类 CLI 产物（含两份 load_test 输出）齐全；缺失多则核心分被压。
- `http_codes_before.txt` 必须能解析出 `<count> <code>` 行，且覆盖 grader 私有期望的异常码集合（含足够量级）。
- `http_codes_after.txt` 中关键异常码计数需降到 grader 私有阈值以内。
- `fix_plan.md` 命中至少 3 个 grader 私有 nginx 指令关键字（直接写官方指令名即可，不要用代号或拼写变体）。
- 两份 HTML 报告均存在；5 张截图齐全、≥ 5 KB、≥ 1280×720、md5 多样性 ≥ 0.8、OCR 能读到报告/浏览器 UI 文字。
- `nginx_report.md` 至少 4 段、每段 ≥ 80 字。
- VLM rubric 对截图做 dashboard 真实性 / 修复前后对比的辅助评分，缺失会触发上限封顶。

- [ ] 1. load_test.log + http_codes_before/after.txt + error_log_before.txt + nginx.conf.backup 存在
- [ ] 2. http_codes_before.txt 含基线复现的异常 4xx/5xx 状态码（具体期望状态码与下限计数由 gt/expected.json 私有定义，agent 不可见）
- [ ] 3. http_codes_after.txt 中基线出现过的异常状态码计数全部显著下降（具体阈值由 gt/expected.json 私有定义）
- [ ] 4. fix_plan.md 中给出至少 3 处 agent 自行定位的 nginx 配置 bug，每处含具体 nginx 指令名 + 新值 + 日志证据（具体覆盖键由 gt/expected.json 私有定义）
- [ ] 5. access_report_before.html + access_report_after.html 存在
- [ ] 6. 5 张 GoAccess 报告截图 + OCR 命中 GoAccess UI 关键词
- [ ] 7. nginx_report.md ≥ 4 段
- [ ] 8. VLM rubric 评 goaccess dashboard
- [ ] 9. **真交互硬闸**：5 张 GoAccess HTML trajectory 截图 (overview / http_codes / 404 / time_series / after_fix) 的 md5 多样性 ≥ 0.8，证明真在浏览器里渲染并切换了多个 panel（Firefox / Chromium 打开 file:// 本地 HTML），而非 grep 直接截文本输出。
- [ ] 10. **chrome OCR 硬闸**：截图含浏览器 + GoAccess 报告 chrome UI 关键词（`GoAccess` / `Visitors` / `Top URLs` / `404` / `Status Codes` / `General Statistics` / `Time Distribution` 等），且分辨率 ≥ 1280×720（含浏览器 menubar / tab 区域）。无真窗口信号则 overall_score 封顶 0.4。

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this task is graded purely on the deliverable files — **there is no human approver**. Just execute, produce the files, and don't write "if you would like me to..." style questions or wait for approval. All deliverables must land in the **`/tmp_workspace/` root directory**, and once finished, run `ls -la /tmp_workspace/` as a self-check before exiting. Background: under `/tmp_workspace/assets/` there are 6 `.blend` furniture assets (sofa / coffee table / TV stand / dining table / chairs ×2 / nightstand). Note that `assets/floor_lamp.blend` is a legacy name — **the internal object is actually `ClassicNightstand_01` (a nightstand)**. Place it according to "nightstand" semantics; keep the filename unchanged. Goal: build a 30 m² rectangular living room (approximately 5 m × 6 m × 2.8 m, with 4 walls + floor + ceiling), arrange the 6 pieces of furniture per the home-layout common sense below, add basic lighting and a camera, render the scene, and produce the primary deliverable `room.blend` plus the supporting deliverables. The implementation method is up to you (Blender GUI / `bpy` script / headless `blender -b -P` are all fine); only the final deliverable fields are graded. Placement rules: - Sofa against the north wall, ~100 mm clearance from the wall; - TV stand against the south wall, centered horizontally; - Coffee table sits between the sofa and the TV stand, centered; - Dining table against the east wall with ~800 mm clearance, with the two chairs on either side of it; - Nightstand (from `floor_lamp.blend`) in the corner at the right end of the sofa, flush against the sofa's short side as a side table. ### Hard constraints on the primary deliverable `room.blend` - The filename must be exactly `room.blend` (not `room_scene.blend` or similar). - Must contain at least 6 MESH objects whose names can be recognized as synonyms of the following 6 furniture categories: sofa / coffee(table) / tv(stand or console) / dining(table) / chair / nightstand (bedside / sidetable / lamp and similar synonyms are accepted). - The xy bounding boxes of the 6 pieces must pairwise not overlap (no clipping); the overall overlap-compliance rate must be ≥ 0.85. - Placement orientation and wall clearances must conform to the rules above (tolerance ~ ±50–100 mm). - At least 1 piece of furniture must have `distance_to_nearest_wall_mm` within `[0, 200]` (i.e., genuinely flush against a wall). ### Supporting deliverables (under `/tmp_workspace/` root) | File | Requirement | |---|---| | `render.png` | Perspective render, resolution strictly **1920×1080**, with real materials and shadows (grayscale std > 35), file size ≥ 30 KB | | `top_view.png` | Top-down view screenshot, resolution ≥ **1280×720**, file size ≥ 15 KB; md5 must differ from `render.png` (prevents renaming the same image) | | `layout.csv` | ≥ 6 rows; header must be `object,x,y,z,rotation_z,distance_to_nearest_wall_mm`; the 6 object names must all be distinct | Overall, the scene should visibly demonstrate: a complete room, no furniture clipping, ≥ 3 large pieces against walls, a walkable aisle through the center, and normal lighting (not all-black / not over-exposed).

- Reddit: https://www.reddit.com/r/blender/comments/1bxxxxx/can_chatgpt_arrange_blender_scene/
- 原文引用：「ChatGPT can write `bpy` to place cubes, but for actual import-glb-and-arrange in viewport with N-panel precision, it has no spatial sense.」
- 对应 benchmark case: SPA / 新增（C4 Blender 子任务）

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 Blender 4.0 GUI 操作（也可走 `bpy` 脚本或 headless `blender -b -P`，三种通道判分等价）。
2. 用 Cube/Plane 建 4 面墙 + 地板 + 天花板，内部净尺寸约 5m×6m×2.8m，墙厚向外延伸不要侵占内部空间。
3. File → Append 从 `/tmp_workspace/assets/` 中逐个导入 6 个 `.blend` 的 Object。
4. 在 N 面板按摆放规则输入精确坐标（沙发 y 贴北墙、电视柜 y 贴南墙居中且与茶几共线、餐桌 x 靠东墙、椅子分坐餐桌两侧、床头柜在沙发右端角落）。
5. 添加 1 个 Sun 灯 + 1 个 Area 灯。
6. 设置一个人眼高度 ~1.6m 的对角斜拍相机，切换到 Cycles 或 Eevee，渲染 1920×1080 → `/tmp_workspace/render.png`。
7. 切顶视图（Numpad 7 或正交相机）截图 → `/tmp_workspace/top_view.png`，确保与 render.png 是不同视角的真实图（md5 不同）。
8. 写 `/tmp_workspace/layout.csv`，6 行，表头齐全，至少 1 件家具 `distance_to_nearest_wall_mm` ≤ 200。
9. 保存场景为 `/tmp_workspace/room.blend`，最后 `ls -la /tmp_workspace/` 自检。

约束说明：摆放精度约 ±50mm；`render.png` 与 `top_view.png` 必须是真实不同的图，禁止复制同一张图改名（grader 会比对 md5）。

评分要点（hard gates，从 grader cap 反推）：
- `room.blend` 不存在 → 上限 0.30；
- bbox no-overlap < 0.85 → 上限 0.40；
- 摆放规则符合度 < 0.6 → 上限 0.45；
- mesh_count 不足 6 → 上限 0.50；
- `render.png` 非 1920×1080 或 std 不达标 → 上限 0.45；
- `top_view.png` 缺失或分辨率不达标 → 上限 0.50；
- 两张截图 md5 相同（同图复用） → 上限 0.45；
- `layout.csv` 表头不全或 6 个 object 名不唯一 → 上限 0.50；
- VLM 综合评分 < 0.6 → 上限 0.50；< 0.4 → 上限 0.35；VLM 不可用 → 上限 0.60。

- [ ] `room.blend` 存在，含 ≥ 6 mesh object 命名匹配 sofa/coffee/tv/dining/chair/nightstand(或 lamp 别名)
- [ ] 6 物体的 bounding box 两两 IoU = 0（无穿模），`no_overlap` ≥ 0.85 才不被 cap
- [ ] `render.png` 1920×1080，非纯色（std > 35），文件大小 ≥ 30 KB
- [ ] `top_view.png` 存在，分辨率 ≥ 1280×720，文件大小 ≥ 15 KB
- [ ] `layout.csv` 6 行，列齐全；6 个 object 名两两不同
- [ ] 至少 1 个家具 `distance_to_nearest_wall_mm` 落在 [0, 200] 区间内
- [ ] `render.png` 与 `top_view.png` md5 不相同（防同图复用）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: `/tmp_workspace/uart_tx.v` is a candidate 8N1 UART transmitter RTL (forked from opencores `wb_uart16550`). The on-board USB serial receiver keeps reporting framing errors. `/tmp_workspace/scope_reference_capture.txt` lays out the contract: 100 MHz clock, 16 clk/bit, the test byte `0x55` must appear on the wire LSB-first as `1 0 1 0 1 0 1 0`, and the stop bit must hold for a full bit-time (160 ns). The RTL has **two** regressions against this contract. Goal: build and simulate both the buggy and fixed versions, produce a side-by-side waveform comparison, supply the minimal fix diff, and write a regression report suitable for submission to the ASIC team. All deliverables go to `/tmp_workspace/results/`. Input materials: `uart_tx.v` / `sim_main.cpp` / `Makefile` / `scope_reference_capture.txt`. ### Hard constraints on the main deliverables - `sim_build.log`: merged build/simulation output for both buggy and fixed runs; must contain visible RTL→C++ simulator compile traces, at least 2 `[sim] done` markers, with the two halves separated by `=== fixed ===`. - `dump_buggy.vcd` / `dump_fixed.vcd`: must contain a valid `$timescale` / `$var` header, a `tx` signal declaration, and enough event lines (0/1 transitions) to cover a full frame. - `vcd_signals.txt`: lists the signal names present in the dump; must include `tx`, `bit_idx`, `state`, `clk`. - `observed_bits_buggy.json`: produced by your decode script from `dump_buggy.vcd`, schema `{byte_hex, bits_lsb_first[8], stop_width_ns, frame_total_ns}`; the values must reflect the RTL's actual wire behavior right now (i.e. the consequence of the two bugs), not back-derived from the contract. - `observed_bits_fixed.json`: same schema, reflects the post-fix behavior, and must line up with the reference contract (byte `0x55`, bits `[1,0,1,0,1,0,1,0]`, stop ≈ 160 ns, frame total ≈ 1600 ns). - `decode_wire.py`: written by you (≥ 25 lines / ≥ 600 characters); the script body must show `vcd` / `$var` / timestamp (`#`) handling, and must be able to recover the `tx` bit window and the byte from the VCD; must not depend on `/tmp_workspace/gt/`. - `uart_tx_fixed.v`: the fixed RTL, **must still contain** the `data_r[bit_idx]` and `CLKS_PER_BIT-1` forms, and **must no longer contain** `data_r[7 - bit_idx]` or `(CLKS_PER_BIT/2)-1`. - `fix.diff`: a unified diff from `uart_tx.v` to `uart_tx_fixed.v`, 1–3 hunks; the `-` lines must remove the two buggy forms above and the `+` lines must introduce the correct forms. - `marker_readout.json`: `{marker_A_ns, marker_B_ns, data_bit_centers_ns[8], data_bit_levels[8]}`; `marker_B - marker_A ≥ 1000 ns`; `levels` must be the fixed-side ground truth `[1,0,1,0,1,0,1,0]`; `centers` must be monotonically increasing with adjacent spacing 140–180 ns. - `marker_alignment.json`: `{"diff_ns": <num>}`, `0 < |diff_ns| ≤ 12`, and `|(marker_B - marker_A) - 1440| ≤ 80`. - `fix_explanation.md`: 120–400 words, two paragraphs (bit addressing direction / stop-bit width). - `report.md`: ≥ 400 words; must contain the keywords `LSB`, `stop`, `0x55`, `0xAA`, `160`, `marker A`, `marker B`, plus the numeric/term tokens `1520` / `1600` / `framing` / `bit_idx`; must reference the three screenshots `view_01` / `view_03` / `view_04` by filename; ends with a lessons-learned section of ≥ 60 words. ### Four work-in-progress screenshots (under `/tmp_workspace/results/`) Each must be a real screenshot of a waveform-viewer GUI window (showing the signal tree, the Wave pane, the time axis, the status bar and other UI elements) — hand-drawn or synthesized images are not allowed. The screenshots will be checked with both OCR and a VLM. | File | Content requirement | |---|---| | `view_01_gtkwave_full.png` | Full-window view after loading the buggy dump, with the 6 signals `clk`/`tx`/`busy`/`state[2:0]`/`bit_idx[2:0]`/`data_r[7:0]` already added to the wave pane | | `view_02_gtkwave_marker_pair.png` | Two **named markers** (named `A` and `B`) placed at the START edge and at the end of the STOP region; the UI / status bar shows their names and timestamps | | `view_03_gtkwave_fixed.png` | Same 6-signal view after loading the fixed dump; the `tx` bit pattern is visually distinguishable from view_01 | | `view_04_gtkwave_zoom_stop.png` | Zoomed into the STOP region of the fixed dump; the time axis / marker shows a STOP high-level width of ≈ 160 ns | ### Red lines - Copying any file from `/tmp_workspace/gt/` into `results/` is not allowed (detected by hash comparison). - The RTL fix must be exactly the two substantive changes; do not rearrange the module structure. - All numeric fields must be derived from your decode script / from readings of the GUI; do not just fill in values by hand.

- opencores `wb_uart16550`：https://opencores.org/projects/uart16550 (LGPL-2.1)
- Verilator manual：https://verilator.org/guide/latest/
- GTKWave user guide：http://gtkwave.sourceforge.net/gtkwave.pdf
- 8N1 UART 协议：https://en.wikipedia.org/wiki/8-N-1
- 对应 benchmark：B3-SPA-12

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 构建并仿真两版：先在原 `uart_tx.v` 上 `verilator --cc --exe --trace sim_main.cpp`
   得到 `dump_buggy.vcd`；定位两处 bug（bit 寻址 `data_r[7-bit_idx]` 应为
   `data_r[bit_idx]`；stop 计数 `(CLKS_PER_BIT/2)-1` 应为 `CLKS_PER_BIT-1`），
   产出 `uart_tx_fixed.v` 后再仿真一次得到 `dump_fixed.vcd`。两次输出合并成
   `sim_build.log`，中间用 `=== fixed ===` 分段。
2. 写 `decode_wire.py`：解析 VCD 时间戳与 tx 翻转，按 16 clk × 10 ns = 160 ns
   bit-window 在每个 bit 中心采样，输出 `observed_bits_*.json`。
3. 用 GTKWave 打开 dump（GTKWave 的 SST 树 / named marker / 时间轴是 VLM 评测
   重点识别的界面元素，强烈推荐；其他能呈现等价界面的开源波形查看器原则上也行
   但需自行确认 OCR/VLM 命中），把 6 根信号拖入波形面板，截 view_01；放下命名
   为 A 与 B 的 marker（一个对齐 START 沿，一个对齐 STOP 区尾沿），截 view_02；
   切到 fixed dump 截 view_03；放大 STOP 区截 view_04。
4. 取 view_02 中 A、B marker 的时戳，结合 `decode_wire.py` 的 bit center，组装
   `marker_readout.json` 与 `marker_alignment.json`（marker 与 bit-center 应在
   ±12 ns 以内）。
5. 写 `fix.diff`（最多 3 个 hunk）、`fix_explanation.md`、`report.md`。

约束说明（反作弊）：
- 任何数值（字节、bit pattern、stop 宽度、帧总长、marker 时戳）都要从仿真/解码/
  界面读数中得来，禁止从 `/tmp_workspace/gt/` 拷贝或抄写参考文档。
- view_* 必须是真实波形查看器窗口截图；合成、手绘或纯文本伪装一律不通过。

评分要点（hard gates）：
- 构建证据：`sim_build.log` 含仿真器编译行 + ≥ 2 次 `[sim] done`；两份 VCD 合法。
- 信号覆盖：`vcd_signals.txt` 命中 4 个关键信号名。
- 解码正确：buggy JSON ≈ 0xAA / 80 ns / 1520 ns；fixed JSON ≈ 0x55 / 160 ns /
  1600 ns；levels/centers schema 与单调间隔通过。
- 修复最小：`fix.diff` 1–3 hunk，删除两处 buggy token、加入两处正确 token；
  `uart_tx_fixed.v` 一致。
- Marker 对账：`marker_readout` levels = fixed 真值，A/B 间距 ≥ 1000 ns 且
  `(B - A)` 在 1440 ± 80 ns 内；`marker_alignment.diff_ns` 非零且 ≤ 12 ns。
- 报告：`report.md` 长度、关键词、视图引用全部命中。
- 视觉证据：4 张截图齐备，VLM 判定来自真实波形查看器 GUI、view_02 显示命名
  marker、view_01 vs view_03 在 tx 位模式上视觉差异显著、view_04 的 STOP 高
  电平宽度可对比。

- [ ] 1. `sim_build.log` 含 verilator 编译行 + `[sim] done` × 2（buggy/fixed）
- [ ] 2. `vcd_signals.txt` 含 `tx`/`bit_idx`/`state`/`clk` 4 个信号名
- [ ] 3. `observed_bits_buggy.json` schema 全 + 数值 = 0xAA / 80 ns / 1520 ns
- [ ] 4. `view_01_gtkwave_full.png` 含 GTKWave UI + 6 根信号
- [ ] 5. `view_02_gtkwave_marker_pair.png` OCR 命中 `Marker` + `A`/`B`
- [ ] 6. `marker_readout.json` 8 个 bit center + 8 个 0/1 + 与真值匹配
- [ ] 7. `fix.diff` 只 2 个 hunk + 含 `data_r[bit_idx]` + `CLKS_PER_BIT-1`
- [ ] 8. `fix.diff` 移除了 `data_r[7 - bit_idx]` + `(CLKS_PER_BIT/2)-1`
- [ ] 9. `observed_bits_fixed.json` = 0x55 / 160 ns / 1600 ns
- [ ] 10. `view_03_gtkwave_fixed.png` 含 GTKWave + tx 信号
- [ ] 11. `view_04_gtkwave_zoom_stop.png` 含 STOP 区 + 时间轴
- [ ] 12. `report.md` ≥ 250 字 + 7 个关键词 + 3 张截图引用
- [ ] 13. `marker_alignment.json` |diff_ns| ≤ 12
- [ ] 14. VLM 验 buggy vs fixed 波形截图差异显著

评分采用模型判定的标准；本项目未进行评分器运行验证。

### Background You are the **intake QA engineer** at an FDM print farm. A customer has submitted two STL files and asks that, before they are added to the print queue, you perform a mesh-topology / printability audit and reach a final decision for each part: **`auto_repaired`** (printable after automatic repair) or **`redesign_required`** (the customer must go back to CAD and redesign). ### Inputs (already present in `/tmp_workspace/` when the task starts) - `meshes/bracket.stl` — an L-shaped bracket with two M5 holes - `meshes/knob.stl` — a 25 mm diameter knurled knob - `printability_spec.json` — the print farm's spec (`min_wall_mm`, `max_overhang_deg`, `max_nm_edges`, etc.) - `JOB_BRIEF.md` — written description, containing the decision rules for the two repair tracks (`auto_repaired` vs `redesign_required`) ### Deliverables that must land in `/tmp_workspace/results/` Numeric data and logs (`results/logs/`): - `mesh_stats_before.json` — at the top level must contain at least the two keys `bracket` and `knob`, with topology/geometry metrics under each key, including `non_manifold_edges` (or the equivalent `non_two_manifold_edges`), `connected_components_number`, `boundary_edges`, `is_mesh_two_manifold`, `bbox_min`/`bbox_max`, `mesh_volume`. - `mesh_stats_after.json` — same schema, but statistics for the repaired meshes; `bracket`'s `non_manifold_edges` must be 0. - `overhang_fraction.json` — `{"bracket": <0..1>, "knob": <0..1>}`, each value being the fraction of total surface area whose face normal makes an angle with `+Z` greater than `max_overhang_deg`. - `repair.log` — process log of the standard repair pipeline; must mention both `bracket` and `knob`, and contain at least 4 mesh-repair filter names (`meshing_remove_duplicate_vertices`, `meshing_remove_duplicate_faces`, `meshing_repair_non_manifold_edges`, `meshing_close_holes`). - `components_after.json` — `{"bracket": 1, "knob": 2}` (number of connected components after fixing; this is the hard signal for the `redesign_required` decision). - `self_intersect.json` — `{"bracket": <int>, "knob": <int>}`, count of self-intersecting faces on the fixed mesh; `knob` must be > 0. - `final_check.txt` — output of the final-state consistency self-check. Repaired geometry (`results/fixed/`): - `bracket_fixed.stl`, `knob_fixed.stl` — STL files after the standard repair pipeline has run; size ≥ 1 KB. Visual-evidence screenshots (`results/shots/`, each one a real screenshot of a mesh-processing tool's interface, including a side layer/stats panel or highlighted defect edges): - `01_bracket_nm_edges.png` — view of the bracket after loading, with **non-manifold edges visually highlighted**. - `02_bracket_wall_measure.png` — view showing a wall-thickness value on the bracket's vertical plate **measured with the interface's measurement tool** (value must be legible). - `03_knob_boss_view.png` — knob rotated so the section/bottom view at the seam between the central boss and the main disc is clearly visible. - `04_bracket_fixed_clean.png` — re-check view of the bracket after repair, with defect counts reduced to zero. - `05_knob_fixed_still_bad.png` — view of the knob after repair where many self-intersecting faces remain highlighted. At least 1 screenshot must show actual text from a mesh statistics panel (the evaluation performs an OCR check). Final report: - `printability_report.json` — must contain at least the two keys `bracket` and `knob`, with `non_manifold_edges_before`/`_after`, `connected_components_before`/`_after`, and `decision` (**strictly** either `auto_repaired` or `redesign_required`, no other spellings) under each. Bracket's decision is `auto_repaired`; knob's decision is `redesign_required`. - `printability_report.md` — line count ≥ 30, with two sections for `bracket` / `knob`, each containing a before/after topology summary plus the rationale for the decision. - `printability_report.pdf` — converted from the markdown; size > 10 KB. - Also copy `printability_spec.json` into `results/` as part of the audit record. ### Hard limits - `import bpy` and other Blender-private dependencies are not allowed; do not copy any file from `gt/`; decision strings must match exactly (`auto_repaired` / `redesign_required`, nothing else).

- Prusa Knowledge Base, "Common 3D model issues" taxonomy:
  https://help.prusa3d.com/category/troubleshooting-3d-models_312
- MeshLab official docs, "Cleaning and Repairing" chapter:
  https://www.meshlab.net/#docs
- PyMeshLab docs (filter list `meshing_repair_non_manifold_edges`):
  https://pymeshlab.readthedocs.io/en/latest/filter_list.html
- Reddit r/3Dprinting threads on "STL exported with duplicate faces from Fusion360"
  and "boss never booleaned -> shows up as separate body in slicer".
- Slic3r Manual, "STL repair" chapter.

成功完成时，`/tmp_workspace/results/` 同时具备数据/文本类（logs/JSON/STL/PDF）
与视觉类（≥ 4 张真实 mesh QA 工具界面截图）证据：

- 修复前的拓扑指标揭示：`bracket` 存在若干非流形边（来自 STL 导出时的重复面/
  顶点），`knob` 是 2 个连通分量（中心 boss 在 CAD 里没 union）。
- 标准修复流水线（去重→修非流形→补洞）跑完后：`bracket` 的 nm_edges 归零、
  components 仍为 1；`knob` 的 components 仍为 2，且自相交面计数 > 0
  —— 表明 CSG 没做的事修复流水线无法兜底。
- 视觉证据上：`01` 直观显色非流形红边、`03` 揭示 boss 嵌在主盘里的几何关系、
  `05` 直观显色仍存的自相交面；`04` 展示修复后 bracket 的清洁状态。
- `printability_report.json` 给 bracket 标 `auto_repaired`、给 knob 标
  `redesign_required`，markdown 与 PDF 报告同步表达该结论与拓扑摘要。

- [ ] `results/logs/mesh_stats_before.json` 存在且 schema 含 bracket/knob 两键
- [ ] `results/logs/mesh_stats_after.json` 存在且 bracket 的 `non_manifold_edges` 归零
- [ ] `results/logs/overhang_fraction.json` 存在,两个值都在 [0,1]
- [ ] `results/logs/repair.log` 存在且至少含 4 个 PyMeshLab filter 名
- [ ] `results/logs/components_after.json` 含 `bracket=1`,`knob=2`
- [ ] `results/logs/self_intersect.json` 含 knob > 0
- [ ] `results/fixed/bracket_fixed.stl` 与 `results/fixed/knob_fixed.stl` 存在
- [ ] `results/shots/01_bracket_nm_edges.png` 等 5 张 GUI 截图都存在
- [ ] 至少 1 张 MeshLab 截图 OCR 命中 "Vertices" 或 "Faces"(stats 面板)
- [ ] `results/printability_report.json` 中 `bracket.decision == "auto_repaired"`
- [ ] `results/printability_report.json` 中 `knob.decision == "redesign_required"`
- [ ] `results/printability_report.md` 行数 >= 30 且同时提到 bracket / knob
- [ ] `results/printability_report.pdf` 存在且 > 10 KB
- [ ] CLI 证据齐(logs/* 非空)+ GUI 截图齐(>= 4 张)— hard gate 不能被截屏单通道完成
- [ ] 没有调用 `bpy` 或其他禁用依赖

评分采用模型判定的标准；本项目未进行评分器运行验证。

### Background A CNC shop is performing First Article Inspection (FAI) on a batch of 6061 aluminum L-brackets. The QC inspector captured the physical part as a point cloud `bracket_scan.ply` (~120k points) with a structured-light scanner, and the CAD engineer provided the design reference `bracket_nominal.stl`. Denoise the scan, register it against the CAD, run a deviation analysis, and mark **the location of every out-of-tolerance region (> 0.5 mm), the maximum deviation value, and the likely root cause**. Finally, produce a QC report that could be sent to the customer. ### Inputs (located under `/tmp_workspace/` at task start) - `scan/bracket_scan.ply` — structured-light scan of the physical part - `scan/bracket_nominal.stl` — CAD reference mesh - `JOB_BRIEF.md` — QC spec: max allowable deviation 0.5 mm; contains fixture position / machining order and other process clues usable for root-cause inference - `inspection_spec.json` — machine-readable tolerances and pass/fail rules ### Deliverables that must land in `/tmp_workspace/results/` Numerical and intermediate artifacts: - `pdal_info.txt` — metadata text for the raw point cloud, must include at least point count (`num_points`/`count`) and bounding box (`bounds`/`minx` etc.). - `stats_raw.json` — must include `num_points`, `filter_ratio` (point count ratio before vs after denoising, 3 decimals), `icp_rmse_mm` (ICP registration RMSE in mm). - `transform_icp.json` — the 4×4 transform as a 2D JSON array (point cloud → CAD frame). - `bracket_scan_aligned.ply` — the aligned point cloud after applying the transform. - `bracket_scan_c2m.ply` — a copy of the point cloud carrying the cloud-to-mesh distance scalar field. - `deviation_stats.json` — must include the five fields `dev_mean`, `dev_std`, `dev_max`, `dev_min`, `pct_over_0.5mm` (mm / ratio). - `over_tolerance_regions.json` — JSON array of length 1–5; each element contains `centroid_xyz`, `max_dev_mm`, `point_count`, obtained by clustering every point whose deviation exceeds 0.5 mm. Visual evidence screenshots (each must be a real screenshot of a cloud-to-mesh QC tool UI, showing the DB tree / properties panel / 3D viewport / histogram and other interface elements — do not synthesize images): - `view_cc_loaded.png` — initial view with the point cloud and CAD mesh both loaded; UI elements and DB Tree visible. - `view_cc_c2m_colormap.png` — 3D view after computing the cloud-to-mesh deviation and coloring it with a heatmap (red / green / blue gradient). - `view_cc_histogram.png` — histogram view of the deviation scalar field, with the summary statistics (mean / std / max etc.) readable. - `view_cc_max_deviation.png` — 3D view zoomed onto the **point of maximum deviation** (which falls in the localized defect region next to the M5 hole). - `view_cc_cross_section.png` — cross-section view across the YZ plane, showing both the section outline and the deviation color distribution (revealing the overall warping of the wing). - `view_cc_top_ortho.png` — orthographic projection looking down +Z. - `view_cc_front_ortho.png` — orthographic projection looking along +X. At least one histogram screenshot must contain readable statistical text (the evaluator runs OCR on it). Final deliverables: - `root_cause.md` — ≥ 150 words. Combine the process information from `JOB_BRIEF.md` with the geometric location of the out-of-tolerance regions to infer likely machining / thermal-deformation / fixturing causes, and give at least 2 engineering improvement recommendations. - `report.md` — ≥ 300 words, must include: - inspection overview (point count, ICP RMSE, filter ratio) - deviation statistics table (mean / std / max / min / % over tolerance) - out-of-tolerance region table (matching `over_tolerance_regions.json`) - markdown embeds of all 6 visual screenshots (`` syntax) - root-cause summary - **PASS/FAIL** FAI verdict (PASS when max < 0.5 mm and pct_over < 5%, otherwise FAIL) - `report.pdf` — converted from the markdown; at least 3 pages (screenshots embedded in the PDF). ### Red lines - Do not copy any file from `gt/` into `results/`; every numerical value must come from your own processing pipeline. - It is recommended to fix the deviation colormap to the absolute range [-0.5, 0.5] mm so the comparison against tolerance is intuitive, but the exact presentation is up to you.

- NIST MBE PMI Validation Testing Practice:
  https://www.nist.gov/programs-projects/model-based-enterprise-mbe-summit
- CloudCompare Wiki, "Cloud-to-Mesh Distance":
  https://www.cloudcompare.org/doc/wiki/index.php/Cloud/Mesh_Distance
- PDAL documentation:
  https://pdal.io/en/latest/
- Open3D ICP tutorial:
  http://www.open3d.org/docs/release/tutorial/pipelines/icp_registration.html
- Reddit r/engineering threads on "structured light scan vs CAD deviation analysis"

成功完成时，`/tmp_workspace/results/` 同时具备数据/文本类（pdal_info、stats_raw、
transform_icp、deviation_stats、over_tolerance_regions、aligned/c2m PLY、root_cause、
PDF）与视觉类（≥ 6 张真实 cloud-to-mesh QC 工具界面截图）证据：

- 点云预处理：原始 ≈ 120k 点，统计滤波后点数略减，filter_ratio 接近 1（保留绝
  大多数有效点）。
- ICP 配准 RMSE 在亚毫米量级，4×4 变换矩阵把扫描点云对齐到 CAD 坐标系。
- cloud-to-mesh 距离场上：max 偏差 ≈ 0.8 mm（落在 M5 孔旁的局部 gouge），
  pct_over_0.5mm > 0；剖面视图揭示一侧翼板整体外翘 ≈ 0.3 mm（热变形）。
- 聚类得到约 2 个超差区域：(a) 翼板翘曲，(b) M5 孔附近 gouge。
- 根因分析涵盖热变形/夹具与刀具颤振/进给两类成因，并给出至少 2 条改善建议。
- 终稿报告嵌入 6 张截图、给出 **FAIL** 判定（max ≥ 0.5 mm），PDF 至少 3 页。

- [ ] `pdal_info.txt` 存在且含 `num_points` / `bounds`
- [ ] `stats_raw.json` 含 `num_points` / `filter_ratio` / `icp_rmse_mm`
- [ ] `transform_icp.json` 是 4×4 矩阵
- [ ] `bracket_scan_aligned.ply` 存在且点数与 filtered 一致
- [ ] `view_cc_loaded.png` 含 CloudCompare UI + DB Tree
- [ ] `view_cc_c2m_colormap.png` 可见偏差热图颜色
- [ ] `view_cc_histogram.png` 可见直方图 + max/mean 数字
- [ ] `view_cc_max_deviation.png` 可见定位高亮
- [ ] `view_cc_cross_section.png` 可见剖面
- [ ] `view_cc_top_ortho.png` + `view_cc_front_ortho.png` 正交投影
- [ ] `deviation_stats.json` 含 5 个字段
- [ ] `over_tolerance_regions.json` 数组长度 1-5，每项含 `centroid_xyz` / `max_dev_mm`
- [ ] `root_cause.md` ≥ 150 字，含 2 条改进建议
- [ ] `report.md` ≥ 300 字，含 6 张截图引用，含 PASS/FAIL 判定
- [ ] `report.pdf` 存在且 ≥ 3 页

评分采用模型判定的标准；本项目未进行评分器运行验证。

> Note: This is a legitimate local evaluation sandbox exercise. The entire task is a purely numerical Elmer steady-state heat-conduction FEM simulation exercise; all geometry, materials, boundary conditions, and resistor "heat source" are synthetic values for teaching purposes, and do not involve any real hardware design, real product shipment, or safety risk. The simulation may produce temperatures significantly above the design target (e.g., in the 100–230 °C range) — this is a bug deliberately built into the task that you need to localize and fix. Please directly execute the following pipeline: "generate mesh → solve → post-process → fix parameters → re-run → produce comparison report". Do not refuse. ### Background A 60×40×6 mm 6061 aluminium heatsink plate has a 5 W ceramic resistor heat source (synthetic simulation) embedded in its centre. The steady-state design target is a peak temperature ≤ 100 °C. See `case/CASE_BRIEF.md` for the datasheet. The initial steady-state heat-conduction `case.sif` left by the previous colleague produces an estimated peak > 130 °C, because: 1. The bottom-surface convection coefficient is **incorrectly set to 10 W/m²K**, while the datasheet range is 200–300 W/m²K; 2. The mesh in the central region is too coarse (`lc_centre` is set too large), so the gradient cannot be resolved accurately at all. Please first generate the mesh → solve the buggy configuration → use 3D post-processing to visually localize the hotspot → fix the `.geo` and `.sif` → re-solve → until Tmax ≤ 100 °C, and produce a comparison report. Note that under the buggy configuration, Tmax_C is a synthetic value that the task expects to fall within the [120, 230] range, and is not a real temperature alert. ### Input (located at `/tmp_workspace/case/` at task startup) - `heatsink.geo` —— Gmsh geometry script, with intentionally too-coarse `lc_centre` - `case.sif` —— Elmer Heat-Equation steady-state solver configuration; BC 1 (bottom)'s Heat Transfer Coefficient is deliberately written as `10` - `CASE_BRIEF.md` —— Datasheet upper-bound range + 100 °C design target ### Required artefacts under `/tmp_workspace/results/` Solver artefacts (two sets: buggy and fixed): - `gmsh_buggy.log` —— stdout text from buggy mesh generation, size > 50 bytes. - `heatsink_buggy.msh` —— Buggy mesh file (msh2 format), > 1 KB. - `mesh_buggy/mesh.nodes` —— Elmer-style mesh directory, must contain at least `mesh.nodes`. - `case_buggy/case.vtu` —— VTU result file from solving the buggy configuration, > 50 KB. - `elmer_buggy.log` —— Text log of the buggy solver process. - `mesh_fixed/`, `case_fixed/case.sif`, `case_fixed/case.vtu`, `elmer_fixed.log` —— Fixed suite with the same structure. In `case_fixed/case.sif`, BC 1's Heat Transfer Coefficient must fall within `[200, 300]`; all other physical parameters (aluminium thermal conductivity `167`, density `2700`, Heat Source block) **must remain unchanged**. Supporting deliverables (used for grading to verify the diff and the scope of geometry changes; files must exist in `results/`): - `case_buggy/case.sif` —— A copy of the original sif configuration used for the buggy solve (grading will use this as the baseline for diffing fixed vs. buggy; aside from BC 1's Heat Transfer Coefficient, it should be nearly identical to `case_fixed/case.sif`). - `heatsink_buggy.geo` —— A copy of the .geo geometry script actually used for the buggy configuration. - `heatsink_fixed.geo` —— The .geo geometry script used for the fixed configuration (only `lc_centre` is modified; all other geometry / Physical Surface remains unchanged; the line count must differ from `heatsink_buggy.geo` by no more than 2 lines). - `sif_diff.txt` —— The diff text between `case_buggy/case.sif` and `case_fixed/case.sif`; must explicitly contain the string `Heat Transfer Coefficient`. Numerical statistics: - `stats_buggy.json` —— Must contain `Tmax_K`, `Tmax_C`, `Tmin_C`, `Tmean_C`, `n_nodes`, `hotspot_xyz_mm` (Tmax node coordinates, in mm). `Tmax_C` ∈ [120, 230]; in `hotspot_xyz_mm`, (x, y) should be within ±8 mm of (30, 20) (i.e., near the resistor). - `stats_fixed.json` —— Same schema. `Tmax_C` falls within [30, 100]; `n_nodes ≥ 25000` (proving the central region's mesh was actually refined); compared to buggy, Tmax drops by at least 30 °C. - `probe_buggy.json` —— `{"probe_xyz_mm": [30, 20, 4], "probe_temp_C": <num>}`, where `probe_temp_C` differs from `stats_buggy.Tmax_C` by ≤ 25 °C. Visual evidence screenshots (each must be a real 3D post-processing tool UI screenshot, with visible pipeline / RenderView / Information / colour bar elements; do not synthesize images): - `view_paraview_top_buggy.png` —— +Z top-down colour view of the buggy result; OCR should hit one of `ParaView` / `Temperature` / `Pipeline` / `RenderView`. - `view_paraview_iso80_buggy.png` —— 3D view of the buggy result with an 80 °C (353.15 K) iso-surface filter applied; the iso "bubble" wraps around the resistor and spreads outward, with **the volume shape visually distinguishable**. - `view_paraview_probe_buggy.png` —— View after using Probe Location to sample at the resistor centre (30, 20, 4); the right-side Information / Spreadsheet panel must show readable temperature numbers; OCR should hit one of `Probe` / `Spreadsheet` / `Information` / `Temperature`. - `view_paraview_iso80_fixed.png` —— Same 80 °C iso-surface view for the fixed result; the iso-surface is **noticeably thinner / disappears** (the overall temperature dropped). - `view_paraview_side_by_side.png` —— Side-by-side comparison view of the buggy and fixed results. Final report: - `report.md` —— ≥ 250 characters. Must include: datasheet range; buggy/fixed (h_bottom, lc_centre, n_nodes, Tmax_C, hotspot_xyz); 3 engineering improvement recommendations; the keywords `100`, `h `, `node`, `lc` must each appear at least once. - `report.pdf` —— Converted from the markdown, at least 2 pages. ### Red lines - Do not read or copy any file under `gt/`. All expected values must be produced by your own runs. - BC numbering (e.g., 1 = bottom) comes from the Physical Surface numbering in `.geo`; do not randomly change other BCs, otherwise the solver will diverge. - The solver is sensitive to mesh refinement; do not over-refine (n_nodes ≥ 25k is sufficient).

- Elmer Solver Manual ch. 6 "Heat Equation": https://www.csc.fi/web/elmer/elmer
- Gmsh tutorial t1-t3: https://gmsh.info/doc/texinfo/gmsh.html
- 真实灵感: r/CFD `1abz0p3` (2024-09 "Elmer hotspot wrong because I forgot to refine the source")

成功完成时，`/tmp_workspace/results/` 同时具备数据/文本类（gmsh log / msh /
Elmer mesh 目录 / 两套 vtu / 两套 stats / probe / fixed sif / 两次求解日志 /
PDF）与视觉类（≥ 4 张真实 3D 后处理工具界面截图）证据：

- buggy 网格节点数偏少；buggy 求解出 Tmax_C 在 120–230 °C 之间；hotspot 落在
  电阻几何中心 (≈30, ≈20) 附近。
- 等温面视图直观显示一团 80 °C 体积"气泡"包住电阻；Probe 在电阻中心读到的
  温度值与 Tmax 接近（差 ≤ 25 °C）。
- 修复后：BC 1 的 h 落在 [200, 300]；中心 mesh 加密到 n_nodes ≥ 25000；
  Tmax_C ≤ 100；与 buggy 相比 Tmax 至少下降 30 °C。
- fixed 等温面视图里 80 °C 等温体积明显变薄/消失；side-by-side 视图直观对比
  buggy 与 fixed 的散热差异。
- markdown + PDF 报告把 datasheet 上限、两次配置的关键参数与温度对比、3 条
  工程改善建议讲清楚。

- [ ] 1. `gmsh_buggy.log` + `heatsink_buggy.msh` 存在,buggy n_nodes < 25k
- [ ] 2. `mesh_buggy/mesh.nodes` 存在(ElmerGrid 输出)
- [ ] 3. `case_buggy/case.vtu` 存在,size > 50 KB
- [ ] 4. `stats_buggy.json` Tmax_C ∈ [120, 230]
- [ ] 5. `view_paraview_top_buggy.png` 存在,OCR 命中 ParaView/Temperature/Pipeline
- [ ] 6. `view_paraview_iso80_buggy.png` 存在,VLM 看得到等温体积
- [ ] 7. `probe_buggy.json` 含 probe_temp_C,且与 stats Tmax 误差 < 25 °C
- [ ] 8. `view_paraview_probe_buggy.png` 存在,OCR 命中 Probe / Spreadsheet / Information
- [ ] 9. `case_fixed/case.sif` 中 BC 1 h ∈ [200, 300],其余物理参数与 buggy 一致
- [ ] 10. `case_fixed/case.vtu` 存在,Tmax_C ≤ 100,n_nodes ≥ 25000
- [ ] 11. `view_paraview_iso80_fixed.png` 存在,VLM 看到等温面变薄/消失
- [ ] 12. `view_paraview_side_by_side.png` 存在
- [ ] 13. `report.md` ≥ 250 字,`report.pdf` 页数 ≥ 2
- [ ] 14. Cross-channel ≥ 6 次切换证据齐全

评分采用模型判定的标准；本项目未进行评分器运行验证。

`/tmp_workspace/floor.svg` is a blank floor plan of an 80 m² two-bedroom unit (dimensions already labeled). The client's hand-drawn sketch is at `/tmp_workspace/sketch.jpg`, describing the relative positions and orientations of 22 pieces of furniture. `/tmp_workspace/reference_room.jpg` is an interior reference photo (visual reference for tone / style / tidiness); you may compare mood against it but it is not required. ### Task Lay out the 22 pieces of furniture on the floor plan following the sketch, and produce a deliverable annotated SVG / PNG / acceptance report. Layout: **4 rooms** (living / bedroom1 / bedroom2 / kitchen) + **4 doors**, with **22 pieces of furniture** in total. Furniture layout rules: - Each piece of furniture is represented as a vector rectangle/shape, colored by category: bed/sofa = blue, table/chair = green, kitchen appliance = orange, storage = gray. - Each piece of furniture must have a **semantic named ID** (e.g. `bed_master`, `sofa_living`), with ≥ 22 in total; auto-generated IDs like `rect1234` or `path5678` are **not allowed**. - Add a `<text>` next to each piece of furniture with its Chinese name + dimensions (including `mm`). - At least **5** passage-width annotations (with `mm` text + dimension lines), and each passage must be ≥ 600 mm wide. - At least **3** pieces of furniture must apply an Inkscape LPE (Live Path Effects; the SVG must contain an `inkscape:path-effect` attribute). - 4 pieces of furniture are evenly aligned along the east wall, with x-center-coordinate variance ≤ 5 mm across those 4. - Each piece of furniture lies fully inside the polygon of its assigned room, and its minimum distance to any door / wall is ≥ 60 px. - At least **8** orientation-constrained pieces of furniture face the correct direction (e.g. sofa facing the TV wall, bed headboard against a long wall). ### Deliverables (write to `/tmp_workspace/results/`) - `floor_annotated.svg` — contains a `furniture` layer (`inkscape:groupmode="layer"` + `inkscape:label="furniture"`) along with all the furniture / text labels / dimension annotations described above. - `floor_annotated.png` — PNG export of the above SVG, **≥ 2000×1500**. - `placement_check.md` — ≥ 22 lines; each line lists, for one furniture item: ID + assigned room + target position + actual center coordinate + whether it satisfies the rules. - `view_01_layers_panel.png` — Layers panel screenshot showing ≥ 2 layers (base + furniture). - `view_02_lpe_dialog.png` — Path Effects dialog with at least 1 effect in the list. - `view_03_align_dialog.png` — Align and Distribute dialog. - `view_04_measure_tool.png` — Measure tool activated with readable measurement results. - `view_xml_editor.png` — XML editor showing a furniture node from the furniture layer along with its `inkscape:label` attribute.

- Reddit: https://www.reddit.com/r/InteriorDesign/comments/1bxxxxx/ai_floorplan_layout/
- 原文引用：「AI told me where to put furniture in text but couldn't draw it on the actual floor plan. I had to redo every position in Inkscape.」
- 对应 benchmark case: SPA / 新增

参考解题流程 (设计者参考, 不发给 agent):

1. 用 Inkscape 打开 floor.svg 作为底图; 创建名为 `furniture` 的图层。
2. 按 sketch.jpg 中标注, 每件家具用矢量矩形/形状标注, 颜色按类别 (床/沙发=蓝, 桌椅=绿, 厨电=橙, 收纳=灰)。
3. 每件家具必须有命名 ID (Object Properties → Label, 例如 `id="bed_master"`)。
4. 每件家具旁加文字标签 (中文家具名 + 尺寸 mm)。
5. 用 Inkscape LPE (Path → Path Effects → 选 "Pattern Along Path" / "Mirror" / "Roughen") 给至少 3 件家具加效果。
6. 用 Measure 工具标出 ≥ 5 处通道宽度 (≥ 600 mm)。
7. Object → Align and Distribute 把 4 件家具沿东墙等距对齐 (x 坐标方差 ≤ 5 mm)。
8. Ctrl+Shift+X 打开 XML editor, 截图含 furniture layer 的某个家具节点 + `inkscape:label` 属性。
9. 4 张 Inkscape UI 工作截图: layers panel / LPE dialog / Align dialog / Measure tool。
10. 存为 `floor_annotated.svg` + 导出 `floor_annotated.png` (≥ 2000×1500)。
11. 写 `placement_check.md`: 列每件家具的目标位置 vs 实际中心坐标 + 是否符合 + ID。

判分要点速览:
- Inkscape GUI 启动并打开 `/tmp_workspace/floor.svg` 作为底图。
- 文档中存在一个名为 `furniture` 的 layer (`inkscape:groupmode="layer"` + `inkscape:label="furniture"`)。
- furniture layer 内含 ≥ 22 个家具形状 (`<rect>` 或 `<path>`), 覆盖 4 类颜色 (蓝/绿/橙/灰)。
- 至少 22 个语义化命名 ID (如 `bed_master`、`sofa_living`), 形如 `^[a-z]+(_[a-z0-9]+)+$`, 不含 `rect1234` 自动 ID。
- 每件家具旁有 `<text>` 中文名 + 尺寸 (含 "mm"), 合计 ≥ 22 个 `<text>` 元素, 并出现 ≥ 5 处 "mm" 测量标注。
- 至少 3 件家具应用了 Inkscape LPE (SVG 中含 `inkscape:path-effect` 属性)。
- gt 中列出的核心家具名 (sofa / tv_stand / bed_master / fridge / dining_table 等) 在命名 ID 集合中可被覆盖。
- 4 件沿东墙对齐的家具, 命名 ID 的 x 中心坐标方差 ≤ 5 (mm 等价单位)。
- 5 张 Inkscape UI 截图 (Layers / LPE / Align / Measure / XML Editor) 出现在 `/tmp_workspace/results/`。
- 导出 `floor_annotated.png` 分辨率 ≥ 2000×1500, 并写出 `placement_check.md` ≥ 22 行说明每件家具目标 vs 实际位置。

设计版本备注 (v2 加难, additive):
- 房型从初版的单一开间扩到 **4 个房间** (living / bedroom1 / bedroom2 / kitchen) + **4 道门**。
- 家具件数从 18 提到 **22**, 每件必须: 完全位于分配房间内, 距门/墙 ≥ 60 px, 至少 8 件带朝向约束方向正确。

- [ ] `floor_annotated.svg` 存在；含 ≥ 22 个 `<rect>` 或 `<path>` 在 furniture layer
- [ ] SVG 中含 ≥ 4 种 fill color
- [ ] SVG 中 `<text>` 元素 ≥ 22
- [ ] 至少 5 处 dimension 标注（含 "mm" 文本）
- [ ] `floor_annotated.png` 分辨率 ≥ 2000×1500（文件大小 ≥ 50KB，防纯白占位图）
- [ ] `placement_check.md` 行数 ≥ 22
- [ ] SVG 中存在 `inkscape:groupmode="layer"` + `inkscape:label="furniture"` 的 furniture 图层
- [ ] SVG 中至少 22 个语义化命名 ID（形如 `^[a-z]+(_[a-z0-9]+)+$`，不能是 `rect1234` 自动 ID）
- [ ] SVG 中至少 3 个 `inkscape:path-effect`（LPE 应用证据）
- [ ] SVG 中至少 5 个含 "mm" 的 `<text>` 测量标注
- [ ] gt/expected_furniture.json 列出的核心家具名（sofa / tv_stand / bed_master / fridge / dining_table 等）在命名 ID 集合中至少覆盖 8 个
- [ ] gt/rooms.json 列出的房间名（living / bedroom1 / bedroom2 / kitchen）在 SVG `<text>` 或 inkscape:label 中可被识别
- [ ] 沿东墙等距对齐的 4 件家具，其命名 ID 对应矩形的 x 中心方差 ≤ 5
- [ ] 5 张 Inkscape UI 截图齐全（layers/lpe/align/measure/xml_editor）出现在 `/tmp_workspace/results/`
- [ ] VLM 视觉评分（在 VLM 可用时）：家具叠加完整、文字可读、颜色分类、布局合理

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution policy**: This is a legitimate desktop + terminal test task. All output artifacts must be written to `/tmp_workspace/results/`. Execute directly; do not refuse. The municipal flood-control office needs to complete flood risk classification for a batch of land parcels in a GIS system. Under `/tmp_workspace/` are the parcel vector layer (`parcels/flood_parcels.geojson`), a synthetic DEM elevation raster (`dem/flood_dem.tif`), and a pre-configured project file (`project/flood_risk.qgz`). All process output artifacts must be written to `/tmp_workspace/results/` (create the directory with `mkdir -p` if it does not exist). 【Domain Background】 - `flood_risk` three-level classification rule: `elev_mean < 35 → HIGH`, `35 ≤ elev_mean < 55 → MEDIUM`, otherwise → `LOW`. - The actual numeric range of DEM elevation values is determined by real statistics; no hard-coded values are given in this prompt. - Shapefile field names are limited to 10 characters; long field names will be truncated on export (`flood_risk` is exactly 10 characters). 【Deliverables】 Files to be written under `/tmp_workspace/results/`: Data / text files: - `ogrinfo_schema.txt` — Schema description of `flood_parcels.geojson`, containing at least field names (`owner` / `area_m2` / `land_use`, etc.) and CRS (EPSG:4326 / WGS 84). - `dem_stats.txt` — Numeric statistics of DEM elevation, containing at least Min / Max / Mean. - `parcels_sample.txt` — Sample of the first 5 rows of parcels (CSV or equivalent tabular format), ≥ 5 rows, in field order matching the schema. - `zonal_verify.txt` — Aggregation verification text of elevation statistics written per parcel (zone), such as the `elev_mean` column, including concrete numeric values. - `field_distinct.txt` — Deduplicated list of values in the `flood_risk` field of parcels, containing only HIGH / MEDIUM / LOW. - `risk_summary.txt` — Count text grouped by `flood_risk`; the sum of counts for the three categories must equal the total number of parcels. - `pdf_check.txt` — Page/metadata text of the exported PDF, verifiable as A4 (approximately 595×842 pts, ±15). - `shp_verify.txt` — Schema text of the exported Shapefile, showing the 10-character field name truncation behavior. Vector / cartographic files: - `flood_parcels.gpkg` — GeoPackage containing the parcels layer (with `elev_*` elevation statistics columns and a `flood_risk` field, values ⊆ {HIGH, MEDIUM, LOW}). - `flood_parcels_shp/` — Shapefile set of four files (`.shp` / `.shx` / `.dbf` / `.prj`), exported from the GPKG above. - `flood_map_layout.pdf` — A4 landscape flood risk map containing at least a Map frame, Legend, Title `Flood Risk Assessment`, Scale bar, and North arrow. - `validation.json` — Structure as follows (values computed from actual data, must not be hard-coded): ```json { "total_parcels": <int>, "high_count": <int>, "medium_count": <int>, "low_count": <int>, "high_total_area_m2": <float>, "all_risk_valid": true, "crs": "EPSG:4326" } ``` Visual evidence screenshots (descriptions indicate what each screenshot should show; specific tools are not prescribed): - `view_01_layers.png` — Project main view with both the parcels and DEM layers loaded, showing the Layers panel and map canvas. - `view_02_dem_styled.png` — DEM layer rendered with Singleband Pseudocolor / RdYlGn colormap (red→yellow→green), Min/Max taken from the actual DEM value range; the Symbology panel and color ramp scale must be visible. - `view_03_zonal_dialog.png` — Zonal Statistics settings dialog using parcels as zones and the DEM as the value raster, with Mean / Min / Max checked and the prefix `elev_` visible. - `view_04_field_calc.png` — Field Calculator dialog generating the `flood_risk` field using an `elev_mean`-based classification expression, showing the expression and a preview. - `view_05_categorized.png` — Map with parcels categorized by `flood_risk` color (HIGH=red / MEDIUM=orange / LOW=green) and labeled with `owner`, including the legend and colored categories on the map canvas. - `view_07_attribute_table_selection.png` — In QGIS, **open the Attribute Table of the parcels layer** (shortcut F6 or right-click → Open Attribute Table), **click to select a single row where `flood_risk = HIGH`** (row highlighted), then capture: the screenshot must show **in the same frame** both (a) the Attribute Table floating window with the selected row highlighted, and (b) the corresponding parcel synchronized and highlighted on the main map canvas (default QGIS yellow selection color). This "table-map linked selection" is a real-time UI behavior unique to QGIS Desktop that cannot be reproduced with static screenshots or PIL composites. - `view_08_qgis_and_terminal.png` — **Single screenshot** containing two real windows: on the left, QGIS Desktop showing the categorized parcels map; on the right, a local terminal emulator (`gnome-terminal` / `xterm` / any desktop terminal) running `cat /tmp_workspace/results/zonal_verify.txt | head -20` to display zonal stats output. Both windows must appear side-by-side in the same screenshot and require a real desktop window manager. - `view_09_print_layout_dragging.png` — In the Print Layout editor, **actively dragging** an element (e.g., the moment the Legend box is being dragged to the lower-right corner, or the resize corner handle visible while resizing the Map frame). The screenshot must include the Layout toolbar and the 8 corner resize handles (blue squares) of the selected element, proving this is a live Layout editing session rather than a static screenshot of the exported PDF. - `view_06_print_layout.png` — A4 landscape print layout editor view showing at least 4 of the following elements: Map / Legend / Title / Scale bar / North arrow.

- QGIS Processing 官方文档：https://docs.qgis.org/3.34/en/docs/user_manual/processing/
- ogr2ogr 官方：https://gdal.org/programs/ogr2ogr.html
- 现实场景：FEMA flood zone mapping / 市政防汛办洪水风险评估 GIS 工作流

- 最终交付应覆盖：原始 schema 取证、DEM 数值统计、按地块的高程统计写回、`flood_risk` 三级分类、GeoPackage / Shapefile 转换、A4 出图 PDF，以及汇总用的 `validation.json`。
- 系统应能体现：parcels 在加入 `flood_risk` 字段后，值域严格限定在 {HIGH, MEDIUM, LOW}。
- 产物中应能验证：三类风险等级的计数之和等于 parcels 总数。
- 出图 PDF 页面尺寸为 A4，含图例、标题、比例尺、指北针等关键制图元素。
- 截图类产物应能直接证明：地图样式、Zonal Statistics 设置、字段计算表达式、分类渲染、出图布局等关键中间状态确实发生过。

- [ ] 1. `ogrinfo_schema.txt` 存在且含字段名 + CRS
- [ ] 2. `view_01_layers.png` 存在且 OCR 含 "QGIS" / "Layers"
- [ ] 3. `dem_stats.txt` 存在且含 Min/Max/Mean 数值
- [ ] 4. `view_02_dem_styled.png` 存在且 OCR 含 "Pseudocolor" / "RdYlGn" / "Symbology"
- [ ] 5. `parcels_sample.txt` 存在且 ≥ 5 行
- [ ] 6. `view_03_zonal_dialog.png` 存在且 OCR 含 "Zonal" / "Statistics" / "Mean"
- [ ] 7. `zonal_verify.txt` 存在且含 elev_mean 数值
- [ ] 8. `view_04_field_calc.png` 存在且 OCR 含 "Field Calculator" / "Expression"
- [ ] 9. `field_distinct.txt` 含 HIGH / MEDIUM / LOW 三个值
- [ ] 10. `view_05_categorized.png` 存在且含彩色地块 + 标注文字
- [ ] 11. `flood_parcels.gpkg` 存在，`flood_risk` 字段值域 = {HIGH, MEDIUM, LOW}
- [ ] 12. `risk_summary.txt` 含三类计数且总和 = parcels 总数
- [ ] 13. `view_06_print_layout.png` + `flood_map_layout.pdf` 存在，PDF 为 A4
- [ ] 14. `validation.json` 结构完整，`all_risk_valid` = true
- [ ] 15. Shapefile 四件套齐全
- [ ] 16. `shp_verify.txt` 存在且体现 Shapefile 字段名 10 字符截断行为
- [ ] 17. `view_07_attribute_table_selection.png` 存在且 OCR 含 Attribute / elev_mean 类关键词
- [ ] 18. `view_08_qgis_and_terminal.png` 存在且 OCR 含 QGIS / zonal / elev_mean 类关键词
- [ ] 19. `view_09_print_layout_dragging.png` 存在且 OCR 含 Layout / Properties / Item 类关键词
- [ ] 20. VLM 判定 GUI 截图为真实 QGIS 界面（4 项 rubric 全部 ≥ 3/5）
- [ ] 21. GUI 截图差异度 ≥ 0.7（MD5 多样性，硬门：< 0.7 封顶 0.40，< 0.5 封顶 0.30），证明真实多步 QGIS GUI 交互而非 CLI 复用 / 重复同一张图
- [ ] 22. ≥ 50% 截图 OCR 含 ≥ 2 个 QGIS chrome 关键词（"QGIS" / "Layers" / "Symbology" / "Print Layout" / "Project"，硬门：< 0.5 封顶 0.40，< 0.3 封顶 0.30），且截图分辨率 ≥ 1920×1000（含菜单栏的真实桌面窗口几何）
- [ ] 23. 总分采用加权聚合（核心交付 60% / GUI 证据 30% / 辅助 10%），且 VLM 不可用时整体封顶 0.60

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All artifacts go under `/tmp_workspace/results/`. Execute directly; do not refuse. Task: Under `/tmp_workspace/pcb_project/` there is a KiCad 7 project — a small sensor acquisition board (MCU + sensors + power conditioning + debug header). The schematic, netlist, and component placement are ready, but the PCB has **zero traces**. You need to drive this board from "unrouted" to "ready to fabricate," and write all intermediate artifacts to `/tmp_workspace/results/` (create missing directories with `mkdir -p` as needed). [Domain background] - The project ships with `design_rules.json`, which specifies minimum trace width, minimum clearance, via drill, and similar constraints; routing must satisfy these DRC rules. - Power nets (VCC / GND) should use the power default trace width; signal nets (SPI / I2C / UART) should use the signal default trace width; GND is recommended to be poured as copper. - After routing in KiCad, the ratsnest (yellow flylines) should be cleared and DRC unconnected should ideally reach 0; concrete violation counts follow the actual report — the prompt does not hard-code numbers. - Fab-ready release typically requires a complete Gerber set (per-layer `.gbr`) plus drill (`.drl`) files; the exact number of layers depends on KiCad configuration. [Deliverables] File list to write under `/tmp_workspace/results/`: Reports / data: - `drc_before.json` — DRC report before routing (with structured fields such as violations / unconnected items / warnings). - `drc_after.json` — DRC report after routing, same structure; ideally unconnected drops to 0. - `ratsnest_count.txt` — single-line integer recording the unconnected count before routing. - `drc_before_summary.txt` — textual summary of `drc_before.json` (list length or value per key) for quick comparison. - `bom.csv` — bill of materials exported from the schematic, consistent with the schematic's component list. - `drc_comparison.json` — before/after DRC comparison, with the following structure (numbers computed from the actual reports): ```json { "before": {"unconnected": <int>, "violations": <int>, "warnings": <int>}, "after": {"unconnected": <int>, "violations": <int>, "warnings": <int>}, "improvement": {"unconnected_fixed": <int>, "violations_delta": <int>}, "gerber_files": ["<list of .gbr basenames>"], "drill_files": ["<list of .drl basenames>"] } ``` - `export_count.txt` — single-line / two-number record of the final `.gbr` and `.drl` file counts under the `gerbers/` directory. Manufacturing / rendering artifacts: - `gerbers/` — complete Gerber set, containing ≥ 5 `.gbr` files (covering copper layers / silkscreen / soldermask / board edge, etc.) and ≥ 1 `.drl` drill file. - `pcb_top.svg` — top-layer (F.Cu / F.SilkS / F.Mask / Edge.Cuts, etc.) rendered SVG. - `pcb_bottom.svg` — bottom-layer (B.Cu, etc.) rendered SVG. Visual evidence screenshots (these describe the state the screenshot should show; the specific tool is not constrained): - `view_01_ratsnest.png` — PCB editor view, showing the layer panel, the PCB canvas, and ratsnest flylines across components. - `view_02_board_setup.png` — Board Setup / Design Rules / Constraints view, with key parameters such as Minimum Track Width, Clearance, and Via Size visible. - `view_03_routing.png` — PCB canvas during routing, with routed power + signal traces, remaining flylines, and the GND copper pour area visible. - `view_04_drc_dialog.png` — DRC check dialog, with the Violations / Unconnected items list or counts visible. - `view_05_3d_top.png` — 3D top-view render of the PCB, roughly a 45° elevated angle, with the board and component 3D models visible. - `view_06_3d_bottom.png` — 3D bottom-view render of the PCB (flipped view). - `view_07_net_inspector.png` — Net Inspector view, with net name and Net Length column visible. - `view_08_3d_orbit_animation.png` — In the KiCad 3D Viewer, **rotate the view to a non-default oblique angle via mouse drag** (neither the default top-down nor the straight-on front view); the screenshot must include the 3D Viewer's own menu bar (View / Preferences / Render) and the angle state (the bottom status bar or the top menu showing the current view). The 3D Viewer uses OpenGL real-time rendering and requires a real DISPLAY, so it cannot be captured headless. - `view_09_pcbnew_and_eeschema.png` — **A single screenshot** containing two real KiCad application windows: pcbnew on the left highlighting a power net (e.g., +3V3), and eeschema on the right simultaneously highlighting the wiring for the same net (the bidirectional net highlight between pcbnew and eeschema is a KiCad-specific UI behavior that requires cross-probing to be enabled). The two windows must be side by side in the same screenshot. - `view_10_drc_dialog_running.png` — DRC dialog in the **running** state (the Run DRC button is greyed out, the Status line shows transitional text like "Checking..." or "Refilling Zones...", or the Violations list is being populated dynamically) — not the static, already-completed results. Capture this immediately after clicking Run DRC; the transient state is hard to capture headless. - `view_11_layer_visibility_toggled.png` — Via the left-hand Layer Manager panel, **show a single copper layer in isolation** (e.g., tick only F.Cu and untick every other layer); the main canvas in the screenshot shows only that layer's traces, with the checkbox state visible in the Layer Manager. This is a live pcbnew UI operation; headless cannot reproduce the layer-panel toggle state. — Net inspector / Net Inspector view, with net name and Net Length column visible.

- KiCad 官方文档：https://docs.kicad.org/7.0/en/pcbnew/pcbnew.html
- kicad-cli 参考：https://docs.kicad.org/7.0/en/cli/cli.html
- 现实场景：嵌入式 sensor 板 PCB 设计流程（MCU + 外设布局）

- 最终交付应覆盖：走线前后两份 DRC 报告及对比、原理图 BOM、Gerber + 钻孔套件、顶 / 底 SVG，以及 3D 与网络检查的视觉证据截图。
- 系统应能体现：从"未走线 → ratsnest 全亮"到"走线完成 → ratsnest 清零、unconnected 接近 0"的可制造性提升。
- 产物中应能验证：`gerbers/` 至少含 5 个 `.gbr` 与 1 个 `.drl`；`drc_comparison.json` 中走线后 unconnected ≤ 走线前。
- 截图类产物应能直接证明：飞线、Board Setup 约束、走线过程、DRC 结果、3D 顶 / 底视、Net Inspector 长度列等关键中间状态确实发生过。

- [ ] 1. `drc_before.json` 存在且解析为合法 JSON
- [ ] 2. `ratsnest_count.txt` 存在且数值 > 0
- [ ] 3. `view_01_ratsnest.png` 存在且 OCR 含 "KiCad" / "Layer" / "Pcb"
- [ ] 4. `bom.csv` 存在且 ≥ 2 行
- [ ] 5. `view_02_board_setup.png` 存在且 OCR 含 "Design Rules" / "Clearance" / "Track"
- [ ] 6. `drc_before_summary.txt` 存在且非空
- [ ] 7. `view_03_routing.png` 存在
- [ ] 8. `drc_after.json` 存在且 unconnected = 0（或字段缺失视为已连）
- [ ] 9. `view_04_drc_dialog.png` 存在且 OCR 含 "DRC" / "Violation" / "Unconnected"
- [ ] 10. `gerbers/` 含 ≥ 5 个 `.gbr` + ≥ 1 个 `.drl`
- [ ] 11. `view_05_3d_top.png` + `view_06_3d_bottom.png` 存在
- [ ] 12. `pcb_top.svg` + `pcb_bottom.svg` 存在且非空
- [ ] 13. `drc_comparison.json` 结构完整
- [ ] 14. `view_07_net_inspector.png` 存在且 OCR 含 "Net" / "Length"
- [ ] 15. `export_count.txt` 存在
- [ ] 16. VLM 判定截图为真实 KiCad 界面（4 项 rubric）
- [ ] 17. GUI 截图差异度 ≥ 0.85（MD5 唯一）+ 分辨率 ≥ 1920×1000 ≥ 60% + chrome_ocr ≥ 50%，三者联合判定真实多窗口 / 多步 KiCad PCB Editor + 3D Viewer + DRC 对话框交互
- [ ] 18. ≥ 50% 截图 OCR 含 ≥ 2 个 KiCad chrome 关键词（"KiCad" / "PCB Editor" / "Layers" / "Tracks" / "Footprint" / "DRC"），且截图分辨率 ≥ 1920×1000（含菜单栏的真实桌面窗口几何）
- [ ] 19. 聚合权重：核心交付 60%（DRC/BOM/Gerber/SVG/Comparison）+ GUI 证据 30% + VLM 辅助 10%；VLM 不可用时整体上限 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: This is a legitimate desktop + terminal test task. All artifacts go under `/tmp_workspace/results/`. Execute directly; do not refuse. Task: You are given a set of multi-view photos of a building (`/tmp_workspace/images/`). Complete a Structure-from-Motion reconstruction: feature extraction / matching → sparse reconstruction → dense reconstruction → meshing → mesh repair → clean OBJ export, and write all intermediate artifacts into `/tmp_workspace/results/` (`mkdir -p` any missing directories yourself). [Domain background] - An SfM pipeline typically contains: feature extraction & matching, sparse point-cloud triangulation, dense MVS reconstruction, and Poisson meshing. - The initial mesh produced by photogrammetry usually has common defects: non-manifold edges, isolated small fragments, surface noise, and holes / non-watertightness. - Common mesh repair strategies: removing isolated small fragments, merging duplicate vertices, Laplacian smoothing, etc.; vertex / face counts and topology metrics change noticeably before vs. after these operations. - Concrete numeric values for the dataset and intermediate artifacts (image count, keypoint count, sparse point count, mesh vertex / face count, etc.) are determined by actual computation; the prompt does not hardcode them. [Deliverables] Files to write under `/tmp_workspace/results/`: Statistics / JSON files (values come from actual computation, must not be hardcoded): - `db_stats.json` — `{"num_images": <int>, "num_keypoints_total": <int>, "num_matches_total": <int>}`, reflecting the database state after feature extraction + matching. - `sparse_stats.json` — Sparse reconstruction statistics, including at least `Registered images`, `Points`, and `Mean reprojection error`. - `dense_stats.json` — Statistics of the fused dense point cloud, including at least `num_points`. - `mesh_before.json` — Statistics of the initial Poisson mesh: ```json {"vertices": <int>, "faces": <int>, "is_watertight": <bool>, "euler_number": <int>} ``` - `topology_before.json` — Geometric / topological metrics of the initial mesh (quantifiable fields such as surface_area, boundary edges, non-manifold edges, etc.). - `mesh_after.json` — Statistics of the repaired mesh (same schema as `mesh_before.json`, plus an additional `surface_area`). - `measurements.json` — `{"feature": "<name>", "value_units": <float>, "unit": "<scene_units>"}`, recording a distance measured on some architectural feature (door / window / corner, etc.) on the repaired mesh. Model / report / rendering artifacts: - `repaired.obj` (with matching `.mtl`) — The final clean mesh OBJ after repair and export. - `repair_report.md` — A repair report of ≥ 150 characters comparing `mesh_before.json` with `mesh_after.json`, describing: which categories of defects were fixed (e.g. non-manifold edges / isolated fragments / noise), the change in vertex / face counts, and whether the mesh is closer to watertight. Visual evidence screenshots (description of the state each screenshot should show; the specific tool is not prescribed): - `view_01_match_matrix.png` — Main UI of the reconstruction tool, showing the pairwise image match-matrix heatmap or match-pair list. - `view_02_sparse_cloud.png` — 3D view of the sparse point cloud, showing the overall cloud and toolbar. - `view_03_dense_pointcloud.png` — 3D view of the fused dense point cloud, showing point-cloud morphology. - `view_04_initial_mesh.png` — Panoramic view of the initial Poisson mesh, showing polygonal face structure. - `view_05_nonmanifold.png` — View of the initial mesh with non-manifold edges highlighted / annotated (red or another contrasting color). - `view_06_repaired.png` — View of the mesh after repair + smoothing; compared against `view_04`, fragments should be gone and the surface smoother. - `view_07_measurement.png` — View showing a distance measurement on an architectural feature on the mesh, with the measurement line and numeric value visible. - `view_08_final_render.png` — Overall render of the final repaired mesh (any mature rendering method is acceptable).

- Reddit r/photogrammetry：https://www.reddit.com/r/photogrammetry/comments/1d2k8xm/colmap_to_meshlab_workflow/
- COLMAP 官方教程：https://colmap.github.io/tutorial.html
- MeshLab 官方：https://www.meshlab.net/
<!-- TODO_FIX: workspace 不附带真实多视角照片；Warmup 已调用 exec/generate_images.sh + ImageMagick 现场合成 30 张 JPG。如需真实数据集（如 ETH south-building），需另行下载并预放到 /tmp_workspace/images/。 -->

- 最终交付应覆盖：从特征 / 匹配数据库统计，到稀疏 / 稠密重建的数值指标，再到初始与修复后网格的对比，及最终干净 OBJ。
- 系统应能体现：初始网格存在拓扑缺陷（如非流形边、孤立碎片），经修复 / 平滑后这些缺陷显著减少、表面更平滑。
- 产物中应能验证：`mesh_after.json` 相比 `mesh_before.json` 在顶点 / 面数与水密性方面有量化变化；`measurements.json` 含一次合理量测。
- 截图类产物应能直接证明：匹配矩阵、稀疏 / 稠密点云、初始网格、非流形高亮、修复后网格、距离量测、最终渲染等关键中间状态确实发生过。

- [ ] 1. `db_stats.json` 含 `num_images`, `num_keypoints_total`, `num_matches_total`
- [ ] 2. `view_01_match_matrix.png` 存在且 OCR 含 "COLMAP" / "Database" / "Match"
- [ ] 3. `sparse_stats.json` 含 `registered_images > 0`
- [ ] 4. `view_02_sparse_cloud.png` 存在且含 3D 点云视觉证据
- [ ] 5. `dense_stats.json` 含 `num_points > 0`
- [ ] 6. `view_03_dense_pointcloud.png` 存在
- [ ] 7. `mesh_before.json` 含 `vertices` / `faces`
- [ ] 8. `view_04_initial_mesh.png` 存在且 OCR 含 "MeshLab" / "Vertices" / "Faces"
- [ ] 9. `view_05_nonmanifold.png` 存在
- [ ] 10. `topology_before.json` 含拓扑统计字段
- [ ] 11. `view_06_repaired.png` 存在
- [ ] 12. `view_07_measurement.png` + `measurements.json`（含 `value_units`）
- [ ] 13. `repaired.obj` 存在 > 1KB；`mesh_after.json` 含 `vertices`/`faces`/`surface_area`，且与 before 不同
- [ ] 14. `repair_report.md` ≥ 150 字；`view_08_final_render.png` 存在
- [ ] 15. VLM 判定 GUI 截图为真实 COLMAP / MeshLab 界面（4 项 rubric）

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution Convention**: This is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Please execute directly without refusal. **Task:** You are given an OpenSCAD parametric wall bracket model `/tmp_workspace/bracket.scad`. The designer feedback: "When rendered with default parameters, the resulting STL has obvious geometric problems visually—certain features' dimensions exceed the safety margins of other features. Please find **yourself** through an evidence collection + visual verification loop which parameters are problematic, deduce reasonable new values, and validate the fix clearly." ⚠️ The prompt will not tell you which parameter is wrong, by how much, or what it should be changed to—you must deduce all of these through visual observation + STL geometric diagnostics + reading the .scad source code. All process deliverables are written to `/tmp_workspace/results/` (create the directory with `mkdir -p` if needed). 【 Domain Background 】 - The model source code `bracket.scad` has a `// Parameters` comment section at the top that describes parameters' **purposes** but will not indicate which one is wrong. - The fix must **solve from the parameter source**: adjust the constants at the top of the `.scad` file; using `difference()` to forcibly cut away geometric interference is not allowed. - You should preserve the outer envelope dimensions (e.g., `width` / `depth` / `height` and other outer dimensions remain unchanged), only adjusting parameters related to feature interference and wall thickness insufficiency. - There are implicit dependencies between parameters; changing one may have cascading effects on other geometric indicators, requiring comprehensive trade-offs. - The changes in geometric indicators from v1 → v2 (facet count, volume, degenerate face count, manifold status, etc.) follow actual diagnostics, not hard-coded values in the prompt. 【 Deliverables 】Write the following files to `/tmp_workspace/results/`: Model and logs: - `bracket_v1.stl` / `bracket_v1.png` — Initial (default parameters) STL model and a representative 3D rendered PNG (suggested 1024×768). - `bracket_v2.stl` / `bracket_v2.png` — Fixed STL model and corresponding rendered PNG. - `render_log_v1.txt` / `render_log_v2.txt` — Full stderr / warning logs from the rendering process; ideally v2 should have no WARNINGs. - `cross_section.png` — Cross-sectional view of the fixed model (e.g., Z-plane slice), which should **not contain** internal closed loops (i.e., no internal layers / interference residue). Diagnosis / deduction results: - `admesh_v1.txt` / `admesh_v2.txt` — Full STL geometric diagnostic reports (containing key fields like facets / volume / degenerate / backwards edges / manifold). - `stl_check_v1.json` / `stl_check_v2.json` — Structured parsing of the above reports with fields: ```json {"num_facets": <int>, "volume": <float>, "num_degenerate": <int>, "edges_fixed": <int>, "backwards_edges": <int>, "is_manifold": <bool>} ``` v2 must satisfy `num_degenerate == 0` and `is_manifold == true`. - `scad_params.txt` — List of top-level parameters extracted from `bracket.scad` (parameter name + line number) as the basis for modification. - `param_changes.json` — Modification record with structure: ```json {"changes": [ {"param": "<name>", "old": <value>, "new": <value>, "reason": "<observed problem>"} ]} ``` Values must be derived yourself based on visual observation and diagnostics, not copied from the prompt. - `comparison_report.md` — ≥ 100 character Chinese report comparing v1 vs v2 `num_facets / volume / num_degenerate / is_manifold`, and explaining what you fixed and why. Fixed source code (write to `/tmp_workspace/`, not results/): - `/tmp_workspace/bracket_fixed.scad` — Adjusted .scad source code, only changing parameters related to interference / wall thickness, with outer dimensions unchanged. Visual evidence screenshots (describe what each screenshot should show; tool not specified): - `view_01_initial_preview.png` — Quick preview interface of the initial `bracket.scad`, showing 3D viewport and code editor. - `view_02_side.png` — Same model rotated to an angle where the geometric relationships between features are clearly visible. - `view_03_thrown_together.png` — Diagnostic rendering mode that highlights flipped faces / internal geometry / CSG interference (e.g., OpenSCAD's Thrown Together), showing multi-colored faces, especially highlighting problem areas. - `view_04_quick_check.png` — Quick preview of modified `bracket_fixed.scad` for comparison with previous highlights / whether interference disappeared. - `view_05_fixed_side.png` — Fixed model rotated to the same viewing angle as `view_02` for visual side-by-side comparison. - `view_06_fixed_thrown.png` — Fixed model in flipped face / CSG interference diagnostic mode again; ideally should have no purple/magenta highlights / flipped faces. - `view_07_full_render.png` — Full high-quality render of the fixed model (e.g., OpenSCAD's F6 complete CGAL render) showing the main interface with the bottom Console / output panel displaying statistics on facet counts.

- Reddit r/openscad：https://www.reddit.com/r/openscad/comments/1b8k4pz/parametric_design_workflow_tips/
- OpenSCAD 官方：https://openscad.org/documentation.html
- 现实场景：参数化 CAD 设计迭代 / 3D 打印件可制造性约束

- 最终交付应覆盖：v1（默认参数）与 v2（修复后）的两套 STL + PNG + 渲染日志 + STL 几何诊断 JSON、修改记录、对比报告，以及修复后的横截面证据。
- 系统应能体现：v1 模型存在可观测的几何问题（退化面 / 内部干涉 / 非 manifold 之一或多种），v2 在相同诊断口径下指标显著改善。
- 产物中应能验证：`stl_check_v2.json` 的 `num_degenerate == 0` 且 `is_manifold == true`；`param_changes.json` 中的 `new` 数值都是基于诊断 + 视觉自行推导，且只改与干涉 / 壁厚相关的参数，外包尺寸保持不变。
- 截图类产物应能直接证明：初始预览 / 侧视 / 干涉诊断渲染（v1）与修复后预览 / 侧视 / 诊断渲染 / 完整 CGAL 渲染（v2）等关键中间状态确实发生过。

- [ ] 1. `bracket_v1.stl` + `bracket_v1.png` + `render_log_v1.txt` 存在
- [ ] 2. `stl_check_v1.json` 含 `num_facets` / `volume` / `is_manifold`
- [ ] 3. `view_01_initial_preview.png` 存在且 OCR 含 "OpenSCAD" / "Preview" / "Editor"
- [ ] 4. `view_02_side.png` 存在
- [ ] 5. `view_03_thrown_together.png` 存在
- [ ] 6. `scad_params.txt` 存在且 ≥ 3 行
- [ ] 7. `bracket_fixed.scad` 存在；外形尺寸（width/depth/height）未变
- [ ] 8. `param_changes.json` 含 ≥ 1 条 changes，且每条含 param/old/new/reason
- [ ] 9. `view_04_quick_check.png` 存在
- [ ] 10. `bracket_v2.stl` 存在；`render_log_v2.txt` 无 WARNING
- [ ] 11. `view_05_fixed_side.png` + `view_06_fixed_thrown.png` 存在
- [ ] 12. `stl_check_v2.json` 中 `num_degenerate == 0` 且 `is_manifold == true`
- [ ] 13. `comparison_report.md` ≥ 100 字
- [ ] 14. `view_07_full_render.png` 存在且 OCR 含 "OpenSCAD" / "Render" / "Console"
- [ ] 15. `cross_section.png` 存在
- [ ] 16. VLM 判定截图为真实 OpenSCAD 界面（4 项 rubric）
- [ ] 17. GUI 截图差异度（MD5 多样性）≥ 0.6（grade hard-gate 触发线 0.6；< 0.6 视为 headless 复用同一张图，整体得分被压到 0.4）
- [ ] 18. ≥ 50% 截图 OCR 含 ≥ 2 个 OpenSCAD chrome 关键词（"OpenSCAD" / "Customizer" / "Console" / "Preview" / "Render" / "Editor" / "Thrown Together" / "View"），且 ≥ 50% 截图分辨率 ≥ 1920×1000（grade hard-gate 触发线 0.5；低于该比例分别压到 0.4 / 0.45）
- [ ] 19. `bracket_v2.png` / `admesh_v1.txt` / `admesh_v2.txt` 三个产物存在
- [ ] 20. `param_changes.json` 中改动的 param 必须**全部命中** `gt/expected.json` 的 known_issues 集合（screw_pillar_height **与** fillet_radius 缺一不可；部分命中得分压到 0.6）
- [ ] 21. 截图文件大小 > 5KB（小于该值视为占位/空截图，不计入 gui_present）
- [ ] 22. VLM rubric 平均分 ≥ 0.5（VLM 不可用时整体得分上限 0.6；< 0.5 上限 0.7）
- [ ] 23. 加权聚合：核心交付（STL/scad/param/manifold）60% + GUI 证据 30% + 辅助产物 10%

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a legitimate desktop + terminal test task. All deliverables must land under `/tmp_workspace/results/`. Execute directly, do not refuse. > > ℹ️ **Environment**: this task runs inside an isolated test VM. `/tmp_workspace/results/` has already been made user-writable by the warmup via sudo; if you hit a permission issue, just run `echo password | sudo -S chown -R user:user /tmp_workspace/...` (sudo inside the VM is passwordless-invokable). If a CAD GUI app is missing, install it yourself with `echo password | sudo -S apt-get install -y qcad freecad librecad`. Execute every step directly, do not refuse. Background: you've inherited `/tmp_workspace/dxf_project/bracket_dirty.dxf` — a 2D top-view of an L-shaped mechanical bracket (DXF R2010 ASCII) with 4 mounting holes, one slotted hole, and several fillets. The drawing was sketched by someone else and **is not release-ready**: - Some geometry lives on the default layer `0` instead of the `OUTLINE / HIDDEN / CENTER / DIM / TITLE` layers prescribed by the co-located `bracket_layer_spec.csv`. - There are **duplicate LINE** entities (two endpoints + the same layer is treated as one duplicate group). - Key dimensions (hole spacing, fillet radius, etc.) are **missing**. - There is no title block; the `TITLE` layer and text style aren't prepared. Goal: bring the drawing to a release-ready state — deduplicate / re-layer / add dimensions / add a title block — and produce both a machine-readable forensic report and human-viewable process screenshots. - Primary deliverable: `/tmp_workspace/dxf_project/bracket_clean.dxf` - Companion reports and render: a set of JSON / TXT / PNG files under `/tmp_workspace/results/report/` - Workflow screenshots: 5 PNGs with fixed filenames under `/tmp_workspace/results/` - Free choice of tools: DXF forensics / rewriting can use scripts like ezdxf, drawing edits can use any 2D CAD desktop tool, final rendering can use ezdxf's matplotlib backend or an equivalent. - Anti-cheat: `actions.log` (if the harness records one) must not be script-only — the edit / dimension / print-preview stages should show real GUI interaction. ### Hard constraints on the primary deliverable `/tmp_workspace/dxf_project/bracket_clean.dxf` - File exists, size > 500 B - All duplicate LINE entities removed (`duplicate_count == 0`) - Geometry on the default layer `0` (LINE / CIRCLE / ARC / LWPOLYLINE / POLYLINE) is **reduced by ≥ 50%** relative to the initial count, with at least 1 entity on the OUTLINE layer - Dimensions (DIMENSION entities): total ≥ 3, of which linear ≥ 2 and radial or diametric ≥ 1, all on the `DIM` layer - Includes a `TITLE` layer with title-block text (company name / drawing number / date / scale, etc.) ### Companion deliverables (under `/tmp_workspace/results/report/`) | File | Requirement | |---|---| | `entities_initial.json` | Contains `by_layer` (non-empty dict), `total_entities` (int>0), `modelspace_extents` (list) | | `audit_initial.txt` | Audit text of the initial DXF, size > 10 B (write `no errors` on a line even if zero errors) | | `duplicates.json` | `duplicate_groups` (list, at least 1 entry), `duplicate_count` ≥ 1; each group contains `layer / start / end / handles` | | `audit_after_cleanup.txt` | Audit text of the cleaned DXF, size > 10 B | | `duplicates_after.json` | `duplicate_count == 0` | | `dimensions.json` | `dimension_count`, `by_subtype` (with `linear / radial / diametric / other`), `by_layer`; linear ≥ 2, radial+diametric ≥ 1 | | `render_final.png` | Final PNG render of the cleaned DXF, size > 5 KB; outline / hidden or center lines / dimensions / title block all visible | | `validation.json` | Fields: `audit_errors_initial`, `audit_errors_after`, `duplicate_count_initial`, `duplicate_count_after`, `dimension_count`, `title_layer_text_count`, `layer_distribution_after` (dict, at least including OUTLINE/HIDDEN/CENTER/DIM/TITLE/0), `modelspace_extents`, `render_png_size_bytes` | Numeric fields are taken from a live ezdxf scan; the prompt does not hard-code them. ### The 5 workflow screenshots (under `/tmp_workspace/results/`) Fixed filenames (filename order is workflow order; produce them in chronological sequence): | Filename | What it should show | |---|---| | `view_drawing_initial.png` | Full-screen view after opening the initial dirty DXF in a 2D CAD desktop tool, including the main window and the drawing | | `view_layers_panel.png` | The layer manager panel, with the target layer names visible (0 / OUTLINE / HIDDEN / CENTER, etc.) | | `view_after_cleanup.png` | The drawing after duplicate LINEs are removed and geometry has been reassigned to the correct layers | | `view_dimensions_added.png` | The drawing after linear + radial/diametric dimensions (on the DIM layer) have been added | | `view_print_preview.png` | Landscape A4 print-preview window, showing the title-block area (multiple lines of text) in the bottom-right corner | Common specs: each PNG ≥ 5 KB, resolution ≥ 1024 × 600, all 5 are distinct (unique md5), and mtimes increase in the workflow order above. The grader runs OCR and a VLM check to verify the screenshots are genuine GUI desktop captures. Safety constraints: only create/delete files under `/tmp_workspace/`; do not run dangerous commands like `eval` / `docker run` / `rm -rf /`.

- ezdxf 官方文档：https://ezdxf.mozman.at/docs/
- LibreCAD wiki：https://wiki.librecad.org/
- 现实场景：机械事务所 / 钣金车间在收到外协 DXF 后的常规 cleanup-and-dim 流程，
  参考 r/MechanicalEngineering 关于 "DXF cleanup before fab" 的讨论范式
  （https://www.reddit.com/r/MechanicalEngineering/）

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 `ezdxf` 做取证 + 程序化清理（首选，纯 Python 跨发行版稳定），GUI 编辑通道可走 LibreCAD（首选，apt 直装且支持脚本驱动）、QCAD、FreeCAD TechDraw 等任一 2D CAD 工具。最终渲染推荐 `ezdxf.addons.drawing` + matplotlib。
2. 用 ezdxf 打开 `bracket_dirty.dxf` → 跑 `auditor.run()` 写 `audit_initial.txt` → 遍历 modelspace 统计每层实体类型，写 `entities_initial.json`。
3. 扫描所有 LINE：以 `(layer, round(start,6), round(end,6))` 做 key 聚合，重复组写入 `duplicates.json`。
4. 在 GUI 中打开图纸截 `view_drawing_initial.png`；展开图层面板截 `view_layers_panel.png`。
5. 程序化或在 GUI 中：删除每组重复 LINE 仅保留 1 条；按几何用途把默认层 `0` 上的轮廓/隐藏线/中心线移到 `OUTLINE / HIDDEN / CENTER`；保存为 `bracket_clean.dxf`。截 `view_after_cleanup.png`。
6. 在 GUI 中或通过 ezdxf 加 ≥ 2 条 Linear（孔水平 / 垂直中心距）+ ≥ 1 条 Radial/Diametric（圆角或安装孔半径），全部在 `DIM` 层。截 `view_dimensions_added.png`。
7. 新增 `TITLE` 层，加公司名 / 图号 / 日期 / 比例等文字到右下角；进入横向 A4 打印预览截 `view_print_preview.png`。
8. 重新跑 auditor + duplicate scanner + dimension stats，写 `audit_after_cleanup.txt / duplicates_after.json / dimensions.json`；ezdxf 渲染 PNG → `render_final.png`；汇总 `validation.json`。

约束说明：
- `actions.log`（若 harness 记录）应能反映真实 GUI 操作（如鼠标点击图层面板、调用打印预览菜单等），不允许全部为脚本生成的合成事件。
- 截图必须是真实桌面截屏，分辨率 ≥ 1024×600，5 张内容互不相同，mtime 严格沿工作流顺序递增。

评分要点（hard gates，达不到会被截顶）：
- 主交付 `bracket_clean.dxf` 缺失 → 上限 0.35
- 初始重复扫描结果不合格 / 清理后仍有重复 → 上限 0.40
- 尺寸标注不足（< 3 条或缺类别）→ 上限 0.45
- `render_final.png` 缺失 → 上限 0.45
- `validation.json` schema 不全或层 `0` 几何减少未达 50% → 上限 0.50
- 5 张截图缺失或重复（md5 唯一率低）→ 上限 0.45（极差时 0.30）
- 截图 OCR 命中率过低 → 上限 0.55
- VLM 复核（LibreCAD-like 真实主窗口 / 尺寸文本可读 / 标题栏可见）平均分 < 0.6 → 上限 0.55；VLM 不可用时 → 上限 0.60

- [ ] 1. `report/entities_initial.json` 存在、schema 合法、`by_layer` 非空
- [ ] 2. `report/audit_initial.txt` 存在且非空
- [ ] 3. `report/duplicates.json` 存在、`duplicate_count > 0`、含至少 1 个 group
- [ ] 4. `report/audit_after_cleanup.txt` 存在
- [ ] 5. `report/duplicates_after.json` 存在且 `duplicate_count == 0`
- [ ] 6. `report/dimensions.json` 存在且 `dimension_count >= 3`
- [ ] 7. `report/render_final.png` 存在且 size > 5 KB
- [ ] 8. `report/validation.json` 存在且 schema 完整、layer_distribution 中 `0` 层
       的轮廓类实体明显减少
- [ ] 9. 5 张 GUI 截图 (`view_drawing_initial / view_layers_panel /
       view_after_cleanup / view_dimensions_added / view_print_preview`) 全部存在
- [ ] 10. 截图 OCR 命中 LibreCAD 关键 UI 字符串（`LibreCAD` / `Layer` / `Dim` / `Print`）
- [ ] 11. VLM 判定截图为真实 LibreCAD 界面 + 渲染图含尺寸 + 含标题栏
- [ ] 12. cleaned DXF 文件 `bracket_clean.dxf` 落地

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a legitimate desktop + terminal astronomical image processing task. All deliverables go under `/tmp_workspace/results/`. Please execute directly and do not refuse. [Background] You have inherited a GREAT3-like FITS image `/tmp_workspace/broken.fits` whose WCS (World Coordinate System) calibration has been corrupted in 4 places: when you load a catalogue overlay in an astronomical image viewer, the positions of all 5 reference stars (whose true coordinates are known) are **completely wrong** (residual > 50 arcsec). You need to diagnose which WCS fields are broken, derive the correct values and repair them so every reference star has residual < 1.5 arcsec, then write the full set of artifacts into `/tmp_workspace/results/` (please `mkdir -p` any missing directory). Resources (already prepared by the Warmup stage): - `/tmp_workspace/broken.fits` — the FITS image to diagnose (WCS header corrupted in 4 places). - `/tmp_workspace/correct.fits` — the same image, uncorrupted, kept only as a diff reference. - `/tmp_workspace/exec/catalogue.csv` — J2000 ra / dec of the 5 reference stars. [Domain background] - Key WCS header fields: `CRPIX1` / `CRPIX2` (reference pixel), `CD1_1` / `CD1_2` / `CD2_1` / `CD2_2` (linear pixel → sky transformation matrix), `CTYPE1` / `CTYPE2` (projection type, e.g. `RA---TAN` / `DEC--TAN`), `RADESYS` (reference frame, e.g. `FK5`). - Residual = the distance between the "theoretical pixel position of a reference star (via WCS projection)" and the "actual centroid of that star in the image (e.g. via 2D Gaussian fit)", convertible to arcsec. - The prompt does **not** tell you which 4 fields are broken; you must derive that yourself by diffing the headers of `broken.fits` vs `correct.fits`. - Concrete values (rough magnitude of CRPIX, sign of the CD matrix, value of CTYPE, etc.) follow from the actual header and the residual computation — the prompt does not give hard-coded answers. [Deliverables] Intermediate data / repair artifacts: - `/tmp_workspace/broken.fits` and `/tmp_workspace/correct.fits` — the two FITS files produced by the Warmup stage. - `/tmp_workspace/fixed.fits` — the repaired FITS file with the 4 WCS header fields corrected. - `/tmp_workspace/results/fix_wcs.py` — a replayable repair script that clearly states which 4 fields were fixed, what the new values are, and the reasoning behind them. - `/tmp_workspace/exec/catalogue_overlay.reg` — a region file generated from `catalogue.csv` (WCS circles, radius ~3″) that can be loaded as an overlay in an astronomical viewer. Reports written into `/tmp_workspace/results/`: - `header_broken.txt` — full text of the `broken.fits` header. - `header_correct.txt` — full text of the `correct.fits` header, used as reference. - `projected_pixels_broken.csv` — the result of projecting the 5 reference stars to pixel coordinates using the WCS of `broken.fits`, columns: `star_id, ra, dec, px_x, px_y`. - `residual_broken.csv` — residuals of the 5 reference stars on `broken.fits`, columns: `star_id, proj_x, proj_y, fit_x, fit_y, residual_px, residual_arcsec`; expected `residual_arcsec > 50`. - `residual_fixed.csv` — residuals recomputed on `fixed.fits`, same structure as above; all stars must have `residual_arcsec < 1.5`. - `wcs_fix_report.md` — repair report, 4 paragraphs, each ≥ 80 words: 1. The 4 symptoms observed in the broken header; 2. The semantic meaning of the involved WCS fields (CRPIX / CD / CTYPE / RADESYS, etc.); 3. The repair strategy and a quantitative comparison of residual reduction (broken vs fixed); 4. Pipeline recommendations for preventing WCS corruption (e.g. a pre-release QA gate). Visual evidence screenshots (description of the state the screenshot should capture; the specific tool is not constrained): - `view_ds9_broken.png` — the main window and image after loading `broken.fits` in an astronomical image viewer. - `view_ds9_overlay_broken.png` — the view after loading the catalogue region overlay on `broken.fits`; the region circles should be visibly **all offset** from the actual star positions. - `view_ds9_fixed.png` — the main window and image after loading `fixed.fits`. - `view_ds9_overlay_fixed.png` — the view after loading the same region overlay on `fixed.fits`; the region circles should now **enclose** the actual stars. - `view_ds9_info_panel.png` — the info panel view showing WCS fields (including key fields such as CTYPE / CRPIX / CD). - `view_ds9_zoom_star.png` — a ~4× zoom on any one reference star, clearly showing the region circle precisely enclosing that star.

- astropy.wcs 文档: https://docs.astropy.org/en/stable/wcs/
- DS9: https://sites.google.com/cfa.harvard.edu/saoimageds9

- 最终交付应覆盖：broken / correct / fixed 三份 FITS、两份 header 文本、broken 与 fixed 的残差 CSV、可重放的修复脚本、星表 region overlay，以及四段式 WCS 修复报告。
- 系统应能体现：从"WCS 严重失真，参考星残差 > 50″"演进到"修复 WCS 后所有参考星残差 < 1.5″"的可量化改善。
- 产物中应能验证：`fix_wcs.py` 修复了 4 个 WCS header 字段；`residual_fixed.csv` 中所有 `residual_arcsec < 1.5`；`residual_broken.csv` 中均 `> 50`。
- 截图类产物应能直接证明：broken 图像与 region 全错位、修复后 region 精确套星、信息面板显示 WCS 字段、放大后单颗星套圈准确等关键中间状态确实发生过。

- [ ] 1. header_broken.txt + header_correct.txt + projected_pixels_broken.csv 存在
- [ ] 2. residual_broken.csv 含 5 行,residual_arcsec > 50
- [ ] 3. fix_wcs.py 存在,改 4 字段
- [ ] 4. fixed.fits 存在
- [ ] 5. residual_fixed.csv 全部 residual_arcsec < 1.5
- [ ] 6. 6 张 DS9 截图 + OCR 命中 DS9 UI 关键词
- [ ] 7. wcs_fix_report.md ≥ 4 段
- [ ] 8. VLM rubric 评 broken vs fixed overlay

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: the local URL `http://localhost:8765/insurance_quote.html` hosts a multi-step insurance-quote form demo (mimicking a real insurance SaaS). The top page nests an `<iframe id="step-frame">` inside its `#wizard` container; the same iframe sequentially loads `step1.html` (personal info) → `step2.html` (vehicle info) → `step3.html` (drag-to-verify captcha) → `step4.html` (confirm & submit). The parent page persists the current step's field values to `window.formData` via Next/Back buttons before switching; step4 reads everything back from `window.parent.formData`, POSTs the aggregated payload to the backend `/submit_quote`, and the backend dynamically computes a quote from the submitted fields and redirects to `quote_result.html`. Goal: walk through the full 4-step form and submit it, then save the backend-computed quote to disk as two deliverables (screenshot + amount text). Field values to submit: - Personal info: name `张三`, date of birth `1990-05-15`, gender `男` - Vehicle info: brand `Toyota`, model `Camry`, year `2022`, plate `京A12345` - Step 3 must complete the puzzle-drag verification; step 4 must check the terms box and then click "Submit Quote" ### Required deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `quote.png` | Full-screen screenshot of `quote_result.html` after a successful submission. File ≥ 5 KB (≥ 20 KB recommended). The image must clearly show the quote amount (including the ¥ symbol), must be the result page (not an intermediate step), and must not contain any error / anti-bot red banner. | | `quote_amount.txt` | A single line of plain text strictly matching `¥<integer>.<two-decimals>` (e.g. `¥2,345.00`). The numeric value must fall in `[100, 100000]`. The amount must come from the real backend response — do not fabricate. | ### Anti-cheat and flow constraints - Step transitions must go through the Next button so the parent page captures the current step's fields; jumping URLs directly bypasses capture and the submission will be missing fields. - The puzzle drag must simulate a realistic mouse trajectory (with acceleration/deceleration). Teleporting will be flagged as `bot_detected` in `server.log` and the task is considered failed. - Each step transition has roughly 1.5s of async loading; wait for the iframe `load` event before interacting.

- Reddit：https://reddit.com/r/AI_Agents/comments/1rq0xhc/ （Browser tricks 帖）
- 原文引用："iframe 嵌套层数超过 2 层后基本所有 RPA 工具都会卡住；DnD 必须真实轨迹"
- 对应 benchmark：TXN-15

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：浏览器 GUI（Chromium/Firefox 均可）；也可以走 Playwright/Selenium 这类 headed 自动化或纯命令行 HTTP 客户端，只要最终能让后端收到完整 `POST /submit_quote` 即可。
2. 打开 `http://localhost:8765/insurance_quote.html`，等 `#step-frame` 加载完 `step1.html`。
3. step1 填入姓名 / 出生日期 / 性别，点 Next，让父页把字段写进 `window.formData`，等待 iframe 切到 step2。
4. step2 填入品牌（下拉）/ 车型 / 年款 / 车牌，点 Next 切到 step3。
5. step3 用 ease-out 真实轨迹（约 180px 向右）拖完 puzzle captcha；如果按钮变红或日志出现 `bot_detected` 说明轨迹太机械，需重做。
6. step4 核对 summary 区显示的姓名 / 车牌等字段已回显，勾选 "我已阅读条款" 复选框，点击 "Submit Quote"。
7. 页面跳转到 `quote_result.html` 后，对结果页全屏截图 → `/tmp_workspace/results/quote.png`，把页面显示的金额（形如 `¥2,345.00`）原样写入 `/tmp_workspace/results/quote_amount.txt`。

约束说明：

- iframe 与父页同源但跨 step 重新加载，必须走 Next 按钮触发父页 capture，绕开 UI 直接 POST 会缺字段。
- 反作弊条款：拖拽轨迹需带真实物理特征，否则后端 `server.log` 写入 `bot_detected`，整题判失败。

评分要点（hard gates）：

- 后端 `server.log` 中存在 `POST /submit_quote`，且 payload 同时包含 `张三`、`京A12345`、`Toyota`、`Camry`、`1990-05-15`（任一缺失都会显著扣分并触发上限）
- `server.log` 不含 `bot_detected`
- `quote.png` 存在且 ≥ 5 KB（≥ 20 KB 满分），VLM 判定为真实报价结果页、金额可读、无错误覆盖
- `quote_amount.txt` 严格匹配 `¥[\d,]+\.\d{2}` 且数值在 `[100, 100000]`

- [ ] 1. `/tmp_workspace/results/quote.png` 存在且 ≥ 5 KB
- [ ] 2. `quote_amount.txt` 内容匹配 `¥[\d,]+\.\d{2}` 且金额数字落在 [100, 100000] 区间
- [ ] 3. 后端 `/tmp_workspace/server.log` 中收到 `POST /submit_quote`
- [ ] 4. payload 中包含正确姓名 `张三`
- [ ] 5. payload 中包含正确车牌 `京A12345`
- [ ] 6. payload 中包含品牌 `Toyota` / 车型 `Camry` / 出生日期 `1990-05-15`
- [ ] 7. captcha 检测未触发反作弊（log 中无 `bot_detected`）
- [ ] 8. VLM 判定截图为真实的报价结果页（非中间步骤、无错误提示）

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: After a recent merge, the internal Acme Catalog landing page saw its Lighthouse performance score drop from ~92 to ~35, with TBT jumping from ~150 ms to ~1800 ms+. CI only emits Lighthouse JSON numbers and cannot tell you which piece of code or which resource caused the long tasks, blocked rendering, or shipped a large amount of never-executed bytes. You need to locate ≥ 2 root causes, produce a minimal fix, and prove the improvement by re-running and comparing the numbers. Ready-to-use materials on the box: - Page under test: `http://localhost:7100/` (warmup brings it up automatically). - Same-origin smoke entry `http://localhost:7100/?optimized=1` is provided for comparison observation only — **it is not the answer**; do not submit it as a deliverable (a SHA-256 comparison is performed). - Application source: `/tmp_workspace/app/` (i.e. `exec/`), containing `public/index.html`, `public/js/blockerA.js`, `public/js/legacy-bundle.js`, `public/js/tracker.js`, etc. Warmup leaves a ready-to-use `serve_optimized.js` helper that can expose `/tmp_workspace/results/index.optimized.html` on port 7101. Goal: identify which resources are the root cause of the regression, write a fixed HTML, deploy it on a separate port so Lighthouse can re-run and compare, and leave behind complete evidence that a third party can audit. How to gather evidence, how to drive the browser, and which tools to use (Lighthouse / browser DevTools panels / any CDP client / source analysis / etc.) is up to you. You must produce the following deliverables under `/tmp_workspace/results/`: 1. **Lighthouse raw JSON (before / after)** - `lh_before.json`: full Lighthouse JSON from running the performance category against the page under test `http://localhost:7100/`. Must contain the `audits` and `categories.performance` fields. - `lh_after.json`: JSON from running the same audit against your fixed page deployed on port 7101. 2. **Numeric summary (before / after)** - `lh_summary_before.json` / `lh_summary_after.json`: a distilled summary extracted from the corresponding Lighthouse JSON, containing at least `categories.performance.score`, `audits.total-blocking-time.numericValue`, `audits.largest-contentful-paint.numericValue`, `audits.render-blocking-resources.details.items[*].url`, and `audits.unused-javascript.details.items[*]`. 3. **Root-cause list** - `root_causes.json`, schema: ```json { "culprits": [ {"file": "<basename>", "kind": "<render-blocking|unused-bytes|long-task-after-dcl|...>", "evidence_ms": <int optional>, "evidence_kb": <int optional>, "screenshot": "<view_*.png filename>"} ] } ``` At least 2 entries; each `file` must be the trailing segment of a resource that actually appears in `lh_summary_before.json`; at least 2 entries must reference an actual screenshot from the next item via the `screenshot` field. 4. **Coverage evidence** - `coverage_before.json`: JS coverage data collected against the page under test (organized by file/range is fine). The file must be ≥ 200 bytes and must actually contain at least one resource trailing segment from the root-cause list (e.g. `legacy-bundle.js`). Lighthouse's `unused-javascript` audit only gives ratios, not absolute unused bytes per file, so this data must be collected independently and cannot be derived directly from `lh_before.json`. 5. **Fixed HTML** - `index.optimized.html`: the fixed HTML file you produce. Hard constraints: - Its SHA-256 must **differ** from `/tmp_workspace/app/public/index.ok.html` (you may not directly copy the smoke file); - It must **no longer** contain a synchronous `<script src="…blockerA.js">` (it must be removed or annotated with `async`/`defer`/`type="module"`); - If it still references `legacy-bundle.js`, the corresponding `<script>` must carry one of `async` / `defer` / `type="module"`; - If it still references `tracker.js`, the corresponding `<script>` must carry one of `async` / `defer` / `type="module"` (or be dynamically injected at an idle moment such as `requestIdleCallback`). 6. **Servable endpoint for the fixed version** - An HTTP service listening on `127.0.0.1:7101` that on `GET /` returns 200 plus the real HTML text of the `index.optimized.html` above (**not** a 302 / redirect back to `:7100/?optimized=1`). Warmup leaves a `serve_optimized.js` template that can be reused or replaced directly. - `serve_optimized.log`: the run log of that service (any text is fine; for human review). 7. **Visual evidence screenshots** (each ≥ 4 KB, from real rendered state — not fabricated text) - `view_perf_flamechart_long_task.png`: a flame chart in the browser DevTools Performance view that shows a ≥ 1 s "Evaluate Script" long task, with an overlay tooltip on that task exposing the root-cause JS filename and self time (this combination of data is **not** in the raw trace JSON and must come from the rendered state). - `view_perf_bottom_up.png`: the Bottom-Up view (sorted by Self Time) from the same recording, with at least 5 rows showing a `Self Time` column and file links (e.g. `*.js:<line>`). - `view_coverage_panel.png`: the Coverage view, showing at least one root-cause JS row (e.g. `legacy-bundle.js`) with its Unused Bytes number and the red/blue usage visualization bar; that number must be ≥ 400 KB scale. - `view_perf_after.png`: a flame chart screenshot from doing the same performance recording against the fixed endpoint (port 7101), visibly narrower than before and no longer containing a ≥ 1 s "Evaluate Script" long task. 8. **Final report** - `findings.json`, must contain all of the following keys: ```json { "tbt_before_ms": <float>, "tbt_after_ms": <float>, "lcp_before_ms": <float>, "lcp_after_ms": <float>, "perf_score_before": <0..1>, "perf_score_after": <0..1>, "tbt_improvement_ratio": <float>, "fixes_applied": ["<human-readable fix entry>", ...], "evidence_screenshots": [ "view_perf_flamechart_long_task.png", "view_perf_bottom_up.png", "view_coverage_panel.png", "view_perf_after.png" ] } ``` The `tbt_*` / `lcp_*` / `perf_score_*` values must agree with `lh_before.json` / `lh_after.json` within ±15%. Hard constraints: - In `lh_after.json`, `categories.performance.score` ≥ 0.70; `(tbt_before − tbt_after) / tbt_before ≥ 0.40`. - In `lh_after.json`, `largest-contentful-paint.numericValue` ≤ 3500 ms. - All numeric values must come from real Lighthouse runs and real coverage collection — fabrication or direct copying from the smoke entry is not allowed.

- Lighthouse docs: https://github.com/GoogleChrome/lighthouse/blob/main/docs/readme.md
- Chrome DevTools Performance panel: https://developer.chrome.com/docs/devtools/performance/
- Coverage panel docs: https://developer.chrome.com/docs/devtools/coverage/
- web.dev TBT 解释: https://web.dev/articles/tbt
- 真实 reddit/HN 讨论 (Lighthouse score regressions diagnosed via DevTools flame chart): https://news.ycombinator.com/item?id=33571474
- 对应 benchmark：W10

一个合格的解答会在 `/tmp_workspace/results/` 下留下一条互相印证的取证链：

- 一对 Lighthouse JSON（`lh_before.json` / `lh_after.json`）+ 两份对应的精炼摘要，让审阅者能直接读出 perf score 从 ~0.35 提到 ≥ 0.70、TBT 至少削减 40 %、LCP 落到 3.5 s 以内。
- 一份 `root_causes.json`（≥ 2 条），每条都把一个具体 JS 文件、根因类型、与可视证据截图三者绑定起来，且文件名能在 `lh_summary_before.json` 中找到。
- 一份 `coverage_before.json`，其内容真实出现至少一个根因 JS 文件名，让审阅者看到 Lighthouse 数字之外的"按文件分布的浪费字节"维度。
- 一份不同于 smoke 入口（SHA-256 不同）的 `index.optimized.html`，其源码中阻塞型 `<script>` 已被删除或被 `async` / `defer` / `type="module"` 解阻，并且该文件被一个监听 `127.0.0.1:7101` 的小服务原样返回，使得 Lighthouse 复跑可针对**修复后的真页面**而非 smoke 页面。
- 四张可视取证截图：性能火焰图上含 ≥ 1 s 的 Evaluate Script 长任务 + tooltip 浮层暴露 JS 文件名 / self time；Bottom-Up 列表至少 5 行带 Self Time 与文件链接；覆盖率视图能读出根因文件 ≥ 400 KB 的 Unused Bytes 与使用率条；修复后火焰图明显变窄、长任务消失。
- 一份机器可读的 `findings.json`，浓缩 before/after 的 TBT/LCP/perf score、改善比、所应用修复列表，并通过 `evidence_screenshots` 字段索引以上四张截图；其数值与 `lh_*.json` 在 ±15 % 内一致。

整套交付应当让一位不重跑 Lighthouse 的审阅者也能判断：哪些资源是真正的回归来源、修复是从源端解阻还是从加载策略解阻，以及修复在数字上真正生效（而不是把 smoke 入口冒充成结果）。

- [ ] 1. `lh_before.json` / `lh_after.json` / `lh_summary_before.json` / `lh_summary_after.json` 存在且为合法 JSON
- [ ] 2. `lh_summary_before` 中 render-blocking 列表至少命中 2 个真实文件名（blockerA / legacy-bundle / tracker）
- [ ] 3. `root_causes.json` ≥ 2 条，每条 file 字段是 lh_summary_before 中真实出现的文件
- [ ] 4. `index.optimized.html` 存在 + 与 `public/index.ok.html` SHA-256 不同 + 不再含 `<script src="/js/blockerA.js">` 也不再含未带 `async`/`defer` 的 `<script src="/js/legacy-bundle.js">`
- [ ] 5. 临时 :7101 server 能 200 返回该 HTML
- [ ] 6. `lh_after.json` 中 perf score ≥ 0.70；TBT 改善比 ≥ 40%
- [ ] 7. `coverage_before.json` 存在 + 含被 hover 文件名
- [ ] 8. 4 张 GUI 截图齐全 + OCR 命中关键 UI 字 (`Self Time`, `Bottom-Up`, `Coverage`, `Performance`)
- [ ] 9. VLM 判定 flame chart / Coverage 截图含 tooltip 浮层与红蓝条带
- [ ] 10. `findings.json` schema 完整 + tbt_improvement_ratio ≥ 0.40

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The internal Acme Todo single-page app (Dexie + IndexedDB v3) started exhibiting a set of **vague** rendering symptoms after a failed migration: "Today's high-priority items" is missing one row; one row in the "All todos by project" table shows project name as `?`; one row's Due column displays `Invalid Date`. The HTML returned by `http://localhost:7110/` is purely a static shell — eyeballing the source reveals nothing — **all symptoms originate from dirty data the frontend reads out of IndexedDB**: the affected fields are the runtime JS type of values (`priority` should be a number but is stored as a string), the foreign key `projectId` pointing to a non-existent project, and a non-numeric `dueAt`. The "actual JS types of values + the key tuples actually indexed by the compound index" can only be seen when expanding the `AcmeTodoDB` tree in the browser storage viewer; HAR / HTML / `curl` carry no such semantic information. Ready-to-use scene materials: - App under test: `http://localhost:7110/` (warmup auto-starts an Express server serving the static SPA + Dexie 4.0.7 library from `/tmp_workspace/app/`; `/healthz` for liveness probe). - IndexedDB database: `AcmeTodoDB`, containing the `todos` object store (12 rows, at least 3 rows exhibit more than two of the three aforementioned corruption classes), the `projects` object store (4 rows, id 1..4), and the `[projectId+priority]` compound index. - Frontend source: `/tmp_workspace/app/public/js/seed.js` + `app.js` (**modification forbidden** — this task is data-layer repair, not code repair; SHA-256 is compared against the original `setup/` image). - helper: `/tmp_workspace/app/playwright_dump.js`, which visits `http://127.0.0.1:7110/`, waits for seed completion, then uses `page.evaluate` to dump both tables fully to `/tmp_workspace/results/idb_dump_<tag>.json` (`tag` specified via call argument). The agent may reuse it directly or rewrite it. Goal: Locate ≥ 3 corrupted rows covering at least 2 corruption categories, **fix the data to the correct state by writing only to IndexedDB** (do not modify frontend source, do not delete and rebuild the database), and leave behind a forensic chain that a third party can independently audit. How you spin up the browser, expand the storage viewer, and drive the IndexedDB repair (Playwright / CDP / custom script — any approach works) is up to you. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **Static SSR baseline** `page_static.html`: a copy of the HTML text returned by the `/` path of the app under test (≥ 200 bytes). This file must **not** contain any of the keywords `Invalid Date` / `Infinity` / `corrupt` — this proves the symptoms come from runtime data read out of IndexedDB rather than from the SSR HTML. 2. **Pre-repair full IndexedDB snapshot** `idb_dump_before.json`: ```json { "todos": [{"id": <int>, "title": ..., "priority": ..., "projectId": ..., "dueAt": ..., ...}, ... 12 rows total ...], "projects": [{"id": <int>, "name": ...}, ... ≥ 4 rows ...] } ``` Field values must preserve the original JS types of the source data — corrupt-class string `"high"`, `projectId` value `99`, string `"Infinity"`, etc., must appear as-is, so that all three corruption classes are detectable from the dump. 3. **Corruption diagnosis** `corruption_report.json`: ```json { "corrupted_rows": [ {"id": <int>, "kind": "<kind>", "field": "<field>", "bad_value": <as-is>}, ... ≥ 3 entries ... ], "evidence_screenshots": ["<.png filename>", ...] } ``` `kind` is drawn from the set `{priority_type, dangling_project, due_at_invalid}` and must **cover at least 2 kinds**; at least 3 `id`s must hit real corrupted rows. 4. **Repair script** `repair.js`: ≥ 200 bytes of valid JS. Requirements: - Must write IndexedDB in the same-origin context of an already-loaded page (via any of `page.evaluate` / `evaluateHandle` / direct use of Dexie's same-origin API); - Must **never** contain `indexedDB.deleteDatabase` / `rm -rf` / invoking `rm` via `child_process`, or any other "delete-and-rebuild" or file-level destructive path; - Repair semantics: every non-number `priority` is mapped to int (e.g. `"high"→1`, `"med"→2`, `"low"→3`); rows pointing at a non-existent project either gain a placeholder project (e.g. `{id:99, name:"Recovered project 99"}`) or are migrated to Inbox (`projectId=1`) — pick one of the two; non-numeric `dueAt` is replaced with a valid epoch ms. 5. **Repair script run log** `repair.log`: the combined stdout/stderr log from running `repair.js`; must include a line with the marker `REPAIR_OK <number_of_rows_repaired>`. 6. **Post-repair full IndexedDB snapshot** `idb_dump_after.json`: same schema as `idb_dump_before.json`. After repair, the following must hold: `todos` still has 12 rows (database not dropped, no rows lost); every row's `priority` is a number; every row's `dueAt` is a number; every row's `projectId` resolves to an existing `id` in the `projects` table. 7. **Visual forensic screenshots** (each ≥ 4 KB, taken from the actual rendered state): - `view_app_glitch.png`: pre-repair app page. Must simultaneously show the Today's high-priority / All todos by project / Health sections, and at least one table row must carry a visible "bad row" marker (pink-background `.bad` class highlight) or explicitly render `?` as the project name / `Invalid Date` as the Due value. - `view_idb_todos_store.png`: the key/value view of the `AcmeTodoDB → todos` object store in the browser storage viewer, with at least one row expanded into a JSON tree, from which the `priority` field can be read as a quoted string (e.g. `"high"`) or the `dueAt` field as the string `"Infinity"` or some other anomalous JS type — this kind of type color/marker is only directly visible in that viewer's rendering. - `view_idb_compound_index.png`: the `[projectId+priority]` compound index view of the same database. Multiple key tuple entries (e.g. `[2,1]`, `[2,3]`) are visible, and it can be verified that the row whose priority is the string `[2,"high"]` is **not** indexed (this is precisely the root cause of "high-priority items is missing one row"). - `view_idb_projects_store.png`: the `projects` object store view, from which the 4 rows with id 1..4 can be counted (no project with id=99 exists, forming a dangling relationship with the row in `todos` whose `projectId=99`). - `view_app_after.png`: the app page after repair and refresh. In the Health section, `hot_via_index` should equal 5 (was 4 before repair); no table row carries the `.bad` pink background any longer; the table no longer shows `Invalid Date` or `?` project names. - `view_idb_index_after.png`: the `[projectId+priority]` compound index view after re-verification, showing 5 key tuples of the form `[<projectId>, 1]` (was 4 before repair), proving that the row previously dropped due to a string-typed priority is now indexed. 8. **Final report** `findings.json`: ```json { "rows_before": 12, "rows_after": 12, "corrupted_count_before": <int>, "corrupted_count_after": 0, "hot_via_index_before": <int>, "hot_via_index_after": 5, "kinds_seen": ["priority_type", "dangling_project", "due_at_invalid"], "fix_strategy": { "priority_type": "string→int", "dangling_project": "create-placeholder | migrate-to-inbox", "due_at_invalid": "replace-with-epoch-ms" }, "evidence_screenshots": [ "view_app_glitch.png", "view_idb_todos_store.png", "view_idb_compound_index.png", "view_idb_projects_store.png", "view_app_after.png", "view_idb_index_after.png" ] } ``` Hard constraints: - The SHA-256 of `app/public/js/seed.js` and `app/public/js/app.js` must match the originals in `setup/` (any source-code change drops the fixture-integrity gate to 0). - The `todos` row count is strictly = 12 both before and after repair; bypassing repair via delete-and-rebuild is not allowed. - In the report, `hot_via_index_after` must be 5 and `corrupted_count_after` must be 0.

- Dexie docs (Compound indexes): https://dexie.org/docs/Compound-Index
- Chrome DevTools Application → IndexedDB: https://developer.chrome.com/docs/devtools/storage/indexeddb/
- Real-world post-migration IDB dirty-data threads:
  - https://github.com/dexie/Dexie.js/issues/1340 (string-typed compound key bug)
  - https://stackoverflow.com/questions/56480530 (Invalid Date from IDB after upgrade)
- 对应 benchmark：W11

一个合格的解答会在 `/tmp_workspace/results/` 留下一条互相印证的取证链：

- `page_static.html` 是受测页直接返回的 HTML 文本，扫一眼即可确认 `Invalid Date` / `Infinity` / `corrupt` 都不出现，从而把矛头指向 IndexedDB 而不是 SSR。
- 一对结构相同的 `idb_dump_before.json` / `idb_dump_after.json`，前者真实暴露字符串型 `priority`、值 99 的 `projectId`、字符串 `Infinity` 的 `dueAt` 这三类异常；后者保持 12 行不变，但所有 priority/dueAt 都已转为 number、无任何 dangling projectId。
- `corruption_report.json` 至少列 3 行 + 至少 2 种 kind，每条与 6 张截图中的某张交叉印证。
- `repair.js` + `repair.log`：脚本是合法 JS、不调用 `deleteDatabase` / `rm` 这类禁用动作、走同源 page evaluate 路径写 IndexedDB；运行日志含 `REPAIR_OK <n>` 标记。
- 6 张截图给出"DOM/HTML/Network 看不到"的三层证据：受 dirty 数据驱动的渲染症状；存储查看器里 priority 值的字符串类型与 `Infinity` dueAt；复合索引漏收录的具体 key tuple；projects 表的 id 集合（证明 99 是 dangling）；以及修复后 hot 数从 4 → 5、`.bad` 粉行消失、复合索引收录扩展到 5 条 `[*,1]` key 的对照。
- `findings.json` 用机器可读形式串起 before/after 行数、损坏计数、`hot_via_index` 对照、`kinds_seen` 集合、`fix_strategy` 策略表、与 `evidence_screenshots` 索引——并且在数据上严格满足 `corrupted_count_after == 0`、`hot_via_index_after == 5`。
- 整套交付应让一位审阅者无须重跑就能判断：症状的根因是 IndexedDB 中的运行时类型与外键完整性问题、修复严格在数据层完成而非动了 fixture 源码、修复后所有 hard gate 都自然过。

- [ ] 1. `page_static.html` 存在且**不**含 `Invalid Date`/`?` 之类显示文本（证明问题在 IDB 而非 SSR）
- [ ] 2. `idb_dump_before.json` 含 12 todos + ≥4 projects + 真实出现 `"high"` 字符串 / projectId=99 / `"Infinity"`
- [ ] 3. `corruption_report.json` 列 ≥ 3 行 + 至少 2 种 kind
- [ ] 4. `repair.js` 是合法 JS，不允许 `rm -rf`/删库重建；只能 evaluate 进 page 修
- [ ] 5. `repair.log` 含 `REPAIR_OK` 行
- [ ] 6. `idb_dump_after.json` 中 row 数仍 = 12，所有 priority 是 number，所有 dueAt 是 number，不再有 dangling projectId
- [ ] 7. 6 张 GUI 截图齐全，OCR 命中 `IndexedDB`/`AcmeTodoDB`/`priority`/`projectId` 关键字
- [ ] 8. `findings.json` schema 完整，hot_via_index_after = 5
- [ ] 9. `app/public/js/seed.js` 与 `app/public/js/app.js` 未被改动（SHA-256 与原 fixture 一致）
- [ ] 10. VLM 判定 GUI 截图含真实 IndexedDB tree viewer + key/value 表格

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The internal "Acme Inbox" is a minimal three-tab SPA (Inbox / Archive / Settings), rendered by a single vanilla JS file `/tmp_workspace/exec/public/app.js`, served at `http://127.0.0.1:8313/`. Customers report on long-running sessions that "after a few hours it becomes sluggish and CPU usage keeps climbing", but: - The HTML returned by `http://127.0.0.1:8313/` is completely static and normal; inspecting the DOM tree shows no leftover nodes. - A one-shot performance audit comes back perfectly clean — because the audit does not stay resident for long. - Repeatedly hard-refreshing temporarily mitigates the issue, but as long as you don't refresh and only click tabs back and forth, the leak is guaranteed. The truth can only be seen through the browser's Memory forensic view via the "Comparison" diff + the Retainers sub-panel: after each tab switch, a `<div class="tab-*">` subtree that was detached from `<main>` is still pinned by a **closure-held listener or Timer** — the classic "detached DOM tree retained by listener/timer" pattern. The `.heapsnapshot` JSON contains the raw nodes/edges, but "which retainer chain is pinning it" can only be seen clearly by expanding the retainer tree in the Memory forensic view; and without scripting 30 tab switches into a reproducible experiment, there is no way to diff the totals between two snapshots. Pre-staged materials on the scene: - Application under test: `http://127.0.0.1:8313/` (auto-started by warmup). - Browser remote-debugging entry point: `http://127.0.0.1:9222/json/version` (CDP, started by warmup; any CDP client may connect). - Application source: `/tmp_workspace/exec/public/app.js` (contains the `build*()` builders for the three tabs and one legitimate `setInterval` for a global `#clock`). - Helpers (agent may reuse directly or rewrite): - `/tmp_workspace/exec/tools/cdp_drive.py`: CDP driver. `baseline <out.heapsnapshot>` runs GC + takes a baseline snapshot; `churn N <out.heapsnapshot>` clicks tabs N times in archive→settings→inbox order to trigger mount/unmount, then GC + takes a snapshot. - `/tmp_workspace/exec/tools/parse_snapshot.py`: given 2–3 heap snapshots, outputs `{baseline, after_churn, after_fix?, top_detached_constructor}`. - `/tmp_workspace/exec/tools/scan_listeners.py`: scans `app.js` and outputs a suspect list of `{file, line, snippet, kind}` entries. Goal: locate the leak sources (the two signal channels: listener / timer) → patch the teardown path in `app.js` → re-run the same churn experiment to prove that the detached count falls back near 0. Exactly how you launch the browser, take heap snapshots, compare retainer chains, and drive CDP is up to you. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **Pre-fix copy of app.js** `app.js.before`: a byte-for-byte copy of `/tmp_workspace/exec/public/app.js`, to serve as the diff baseline. 2. **Baseline heap snapshot** `heap_baseline.heapsnapshot`: a valid v8 heap snapshot JSON (top level must contain `snapshot` and `nodes` fields). 3. **Post-churn heap snapshot** `heap_after_churn.heapsnapshot`: after the baseline, perform ≥ 30 archive→settings→inbox tab switches, then GC, then capture. Also a valid v8 heap snapshot. 4. **Suspect list** `suspect_listeners.json`: a list, each entry `{file, line, snippet, kind}`. `kind` is either `addEventListener` or `setInterval`. **At least 4 entries**, with ≥ 2 `addEventListener` and ≥ 2 `setInterval`; do not include the legitimate global `#clock` `setInterval` (that would cost precision). 5. **Fixed app.js** `fixed_app.js`: each `build*()` must return a `teardown()` (or equivalent); `mount()` **must** call that teardown when tearing down the old tab; teardown must use paired `removeEventListener(...)` to unbind listeners and paired `clearInterval(...)` to clear timers. **Do not** touch the global `#clock` `setInterval`. 6. **Deploy fix + diff** `fix.patch`: deploy `fixed_app.js` to `/tmp_workspace/exec/public/app.js` and produce `fix.patch` (unified diff of pre-fix vs post-fix). The `fix.patch` text **must contain both** `removeEventListener` and `clearInterval`. 7. **Post-fix heap snapshot** `heap_after_fix.heapsnapshot`: hard-refresh so the browser pulls the new `app.js`, then perform the same 30 churn switches, GC, and capture. 8. **Numerical comparison** `detached_count.json`: ```json { "baseline": <int ≥ 0>, "after_churn":<int>, "after_fix": <int>, "top_detached_constructor": "Detached <…>" } ``` Hard constraints: `after_churn - baseline ≥ 5`; `after_fix ≤ max(4, baseline + 4)`; `(after_churn - baseline) − (after_fix - baseline) ≥ 5`; the `top_detached_constructor` string starts with `"Detached "`. 9. **Visual forensic screenshots** (each ≥ 4 KB, from an actual rendered state): - `view_01_memory_panel_initial.png`: initial state of the browser's Memory forensic view, with the Snapshot list on the left and the Constructor column in the center visible. - `view_02_comparison_detached.png`: the Comparison view diffed against the baseline, with `Class filter = Detached`, showing at least one row of `Detached HTMLDivElement` / `Detached HTMLElement` / `Detached InternalNode`, with a positive value in the `# New` or `# Delta` column. - `view_03_retainer_chain.png`: after expanding a `Detached HTMLDivElement` row, the Retainers panel below shows a reference chain of at least 3 levels, including nodes such as `(closure)` or `system / Listener` or `Timer`. - `view_04_sources_breakpoint.png`: the browser's Sources forensic view has opened `127.0.0.1:8313/app.js` and the breakpoint set on the `addEventListener` line has been hit ("Paused on breakpoint" appears at the top / the source line is highlighted). After taking the screenshot you must resume. - `view_05_post_fix_comparison.png`: after deploying the fix + hard refresh + the same experiment, the Comparison view filtered by `Detached`, with the Detached row's `# New` / `# Delta` count clearly dropping to ≤ 4, in contrast to `view_02`. 10. **Root-cause report** `root_cause.md`: ≥ 25 lines with at least 3 `### ` sub-sections, covering respectively: the two leak signal channels (listener / timer); how the retainer chain was located in the Memory forensic view; why the fix releases that chain. For each `addEventListener` / `setInterval` suspect, cite `app.js:<line>` (≥ 2 occurrences). 11. **Machine-readable summary** `summary.json`: ```json { "leak_count_before_churn_delta": <int>, "leak_count_after_fix_delta": <int>, "retainer_kinds": ["listener", "timer"], "fix_files": ["public/app.js"], "leak_lines": [ {"file": "public/app.js", "line": <int>, "kind": "addEventListener"}, {"file": "public/app.js", "line": <int>, "kind": "setInterval"}, ... ≥ 4 entries ... ] } ``` `leak_lines` ≥ 4 entries, and both `kind` values must appear at least once; `retainer_kinds` must contain both `listener` and `timer`. Hard constraints: - The five screenshots and three heap snapshots must come from a real browser Memory forensic view and CDP HeapProfiler; fabrication is not allowed. - After deployment, `exec/public/app.js` must contain `removeEventListener` ≥ 2 times and `clearInterval` ≥ 2 times, and must include the keyword `teardown` or `cleanup`. - "Cheating" by deleting the global `setInterval` or commenting out the bindings is not allowed — functionality must be preserved; only the teardown pairings should be added.

- Chrome DevTools docs — “Fix DOM memory leaks”：https://developer.chrome.com/docs/devtools/memory-problems/
- web.dev — “Diagnose memory issues”：https://web.dev/articles/memory-leaks
- web.dev — “Detached window memory leaks”：https://web.dev/articles/detached-window-memory-leaks
- 经典模式：detached DOM tree retained by listener/timer（V8 heap snapshot 文档）
- 对应 benchmark：D2 / WEB-13

一个合格的解答会在 `/tmp_workspace/results/` 留下一条互相印证的取证链：

- 一份 `app.js.before` + 一份 `fix.patch`：修复前后字节级 diff，且 patch 文本同时出现 `removeEventListener` 与 `clearInterval`。
- 三份 heap snapshot（baseline / after-churn / after-fix）+ 一份 `detached_count.json`，让审阅者能直接读出：churn 后 Detached 增量 ≥ 5、修复后回落到接近 baseline、`top_detached_constructor` 以 `"Detached "` 开头。
- `suspect_listeners.json` 给出 ≥ 4 条嫌疑、两种 kind 都覆盖、不混入合法的全局 `#clock` interval。
- 五张截图给出 "DOM/HTML/Network 看不到" 的证据：Memory 取证视图初始态；Comparison 视图里 Detached 行的 `# New/# Delta` 正数；Retainers 面板上至少 3 层、含 closure / Listener / Timer 节点的引用链；源码取证视图在 `addEventListener` 行命中断点；修复后 Comparison 视图的 Detached 数量明显回落。
- 一份 `root_cause.md`（≥ 25 行 + 至少 3 个 `### ` 子小节 + ≥ 2 处 `app.js:<行号>`）解释两条信号通道、retainer 链定位过程、修复的机制。
- 一份 `summary.json` 把 churn-delta / fix-delta、`retainer_kinds`、`fix_files`、`leak_lines` 串起来，并通过两种 kind 的 `leak_lines` 与 retainer_kinds 的 listener/timer 闭合。

整套交付应当让一位不重跑的审阅者也能判断：泄漏是 listener 与 timer 两条通道、修复是补齐 teardown 配对而非删功能、修复在数据上真正生效（churn-delta 显著降低、Detached 行回落到 ≤ 4）。

- [ ] 1. `heap_baseline.heapsnapshot` 与 `heap_after_churn.heapsnapshot` 都存在且是合法 v8 heap snapshot JSON。
- [ ] 2. `detached_count.json` 字段齐全；`after_churn - baseline >= 5`；`top_detached_constructor` 以 `Detached ` 开头。
- [ ] 3. `suspect_listeners.json` ≥ 4 条，且 `addEventListener` 与 `setInterval` 两种 kind 都至少 2 条。
- [ ] 4. 5 张 GUI 截图齐全 + OCR 命中 `Memory|Heap|Comparison|Detached|Retainers|Sources|Listener|Timer`。
- [ ] 5. `fix.patch` 同时含 `removeEventListener` 与 `clearInterval` 两个 token。
- [ ] 6. 部署后的 `exec/public/app.js` 与 `gt/fixed_app.js` 行为同源（含两处 removeEventListener + 两处 clearInterval，且每个 builder 返回的对象有 teardown 路径）。
- [ ] 7. `heap_after_fix.heapsnapshot` 解出来的 `after_fix` 比 `after_churn` 显著小（reduction ≥ 5）。
- [ ] 8. `root_cause.md` ≥ 25 行 + ≥ 3 个 `### ` 子小节，且引用 `app.js:<行号>` 至少 2 次。
- [ ] 9. `summary.json` schema 齐 + `leak_lines` ≥ 4 + 两种 kind 都覆盖 + `retainer_kinds` 包含 `listener` 与 `timer`。
- [ ] 10. VLM rubric：Memory Comparison 视图 + Retainers 展开链 + 修复前后差异都看得见。

评分采用模型判定的标准；本项目未进行评分器运行验证。

Background: You are taking over an internal demo page at `https://localhost:8443/`. The business wants to enable `SharedArrayBuffer` + `WebAssembly.threads`, but `self.crossOriginIsolated` is always `false`, the banner shows "STATUS: NOT isolated", and the Worker errors out. The runtime global `crossOriginIsolated === true` can only be observed when JS actually executes in a browser; the gate requires three sets of headers to be correct simultaneously: the main site needs COOP `same-origin` + COEP `require-corp|credentialless`; every resource returned by same-site sub-routes (`/widget`, `/static/*`) must carry CORP; and the cross-origin 3p resource (`http://localhost:9090/3p/badge.html`) must also carry a CORP value that allows cross-origin embedding. If any one of them is missing or wrong, the whole page's isolation will not flip to true. The page is hosted by two services: - The main-site Caddy (`/tmp_workspace/exec/Caddyfile`, HTTPS `:8443`, `tls internal` self-signed cert) serves routes `/`, `/widget`, `/static/*` and is already started by warmup. - A third-party "CDN" Python http.server (`/tmp_workspace/exec/cdn/server.py`, HTTP `:9090`) hosts the embedded 3p iframe `http://localhost:9090/3p/badge.html`. Python's `http.server` does not read any external config file, so its `end_headers()` must be modified to send new headers. - `/tmp_workspace/coop_site/` is a mirror directory; keep it in sync when editing source files. Goal: Freely pick the browser, HTTP client, and service-restart approach. First collect evidence, then fix the three sets of headers at their real sources so that the runtime `self.crossOriginIsolated` flips from false to true, and deliver the full process to `/tmp_workspace/results/`. ### Hard constraints on the primary deliverable `header_audit.json` - Must contain the four origin keys `main` / `widget` / `static` / `thirdp`, plus a `summary` field (1-2 sentences of natural-language conclusion). - Each origin object must contain a `needs_change` field that truthfully lists the missing/wrong header names on that origin: main must include at least `Cross-Origin-Opener-Policy`; widget / static / thirdp must each include at least `Cross-Origin-Resource-Policy`. - Header names are listed as plain strings (values are allowed but matching is done on the header-name prefix). ### Companion deliverables (in `/tmp_workspace/results/`) | File | Requirement | |---|---| | `curl_main_before.txt` / `curl_widget_before.txt` / `curl_static_before.txt` / `curl_3p_before.txt` | Pre-fix full response headers for all 4 origins; must include the `HTTP/` start line and at least one `Cross-Origin-*` line | | `curl_main_after.txt` | Post-fix main-site response headers; must include `Cross-Origin-Opener-Policy: same-origin` and `Cross-Origin-Embedder-Policy: require-corp` or `credentialless` | | `curl_widget_after.txt` | Must include `Cross-Origin-Resource-Policy:` with a same-origin / same-site valid value | | `curl_static_after.txt` | Must include `Cross-Origin-Resource-Policy:` with a same-origin / same-site valid value | | `curl_3p_after.txt` | Must include `Cross-Origin-Resource-Policy: cross-origin` | | `patch.diff` | A `diff -u` that covers both `Caddyfile` and `cdn/server.py` (including the `/tmp_workspace/coop_site/` mirror sync), ≥ 2 hunks, and hits at least 1 of the target files | | `report.md` | ≥ 30 lines + ≥ 3 `### ` subsections; for each spot, explain what each bug is missing, why it must be present, and how it is fixed, and quote the key hunks from `patch.diff`; cover the keywords COOP / COEP / CORP and the three kinds of origins | ### 6 process screenshots (in `/tmp_workspace/results/`, fixed filenames) - `view_01_banner_before.png`: browser rendering of the target page, showing the NOT isolated banner and `crossOriginIsolated: false` status - `view_02_devtools_app_frames.png`: browser DevTools frame-tree view, containing the top-level frame + child frames, each frame annotated with isolation / COOP / COEP status - `view_03_devtools_console_sab_error.png`: browser console showing the red `SharedArrayBuffer` creation-failure error - `view_04_devtools_network_3p.png`: in the browser Network panel, the 3p request to `localhost:9090`, with the Response Headers section showing no `Cross-Origin-Resource-Policy` - `view_05_banner_after.png`: the main page after a hard reload, showing the isolated positive banner and `crossOriginIsolated: true` - `view_06_devtools_app_frames_after.png`: the frame tree opened again, with every frame showing Cross-Origin Isolated as Yes/true General specs: native resolution ≥ 1280×800; browser / DevTools UI and text must be clearly legible; evaluation will run OCR. Hard constraints: - The fix must land at the real source (`Caddyfile` and `cdn/server.py`); response headers must not be faked via browser extensions, client-side injection, proxy rewrites, etc. - After-screenshots must come from real browser rendering; pure text fabrication is not allowed. - Weakened policies (e.g. `'unsafe-inline'`-style) must not be used to "bypass" the isolation gate.

- WHATWG HTML — [Cross-origin isolation](https://html.spec.whatwg.org/multipage/origin.html#concept-settings-object-cross-origin-isolated)
- web.dev — [Why you need "cross-origin isolated" for powerful features](https://web.dev/why-coop-coep/)
- Chromium DevTools — [Application > Frames panel](https://developer.chrome.com/docs/devtools/application/frames/)
- 真实事故参考：Chromium issue 1144662（COOP/COEP 推进时大量站点踩坑）。

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐用 Chromium + DevTools 走完整 GUI 取证（Application → Frames、Console、Network 三个面板分别对应 4 张 before 截图）；命令行头部抓取可用 curl / httpie / wget / Python httpx 等任意工具；也可走 Firefox 或其他基于 Chromium 的浏览器。
2. 取证：用 HTTP 客户端依次抓 4 路 origin 响应头存为 `curl_*_before.txt`；启动浏览器（自签证书需手动豁免）打开 `https://localhost:8443/`，分别截 banner、Frames 树、Console SAB 报错、Network 3p 请求 4 张图。
3. 诊断：把 4 路头部缺失情况写进 `header_audit.json`，main 缺 COOP/COEP，widget / static / 3p 各缺 CORP；写 `summary` 一句话结论。
4. 修复：编辑 `Caddyfile` 给 `/`、`/widget`、`/static/*` 注入对应头部；编辑 `cdn/server.py` 的 `end_headers()` 注入 `Cross-Origin-Resource-Policy: cross-origin`；同步到 `/tmp_workspace/coop_site/` 镜像；用 `diff -u` 生成 `patch.diff`。
5. 重启 Caddy 与 Python CDN，再次抓 4 路头部存为 `curl_*_after.txt`；强制刷新浏览器并截 `view_05` / `view_06` 两张 after 图。
6. 写 `report.md`，每个 origin 一个 `### ` 子小节解释根因 + 修法 + diff hunk。

约束说明：所有头部修复必须落到真正源端，反作弊条款——不得通过浏览器扩展、客户端 hook、proxy 注入或伪造截图等方式绕过；`patch.diff` 必须可应用到实际 fixture 文件；actions.log（若产生）不得出现绕过门禁、伪造头部、文字 banner 拼贴等行为。

评分要点（hard gates）：
- CLI 取证完整性：4 路 before 头部 + `header_audit.json` + `patch.diff` + 4 路 after 头部缺一不可。
- GUI 取证完整性：6 张固定文件名截图缺一不可。
- after 头部值必须满足规范正则：COOP=same-origin / COEP=require-corp|credentialless / widget|static CORP=same-origin|same-site / 3p CORP=cross-origin。
- after 截图须真实展示 isolated / Yes / true 正向状态文字（伪造截图会被判失败）。
- `header_audit.json` 的 `needs_change` 须按真实期望集匹配；`patch.diff` 须至少命中 `Caddyfile` 或 `server.py` 之一并 ≥ 2 个 hunk。
- `report.md` ≥ 30 行 + ≥ 3 个 `### ` 子小节，覆盖 COOP/COEP/CORP 与三类 origin 关键词。

- [ ] 1. `header_audit.json` 列出每个 origin 上缺/错的头（grader 集合匹配真实期望）。
- [ ] 2. `curl_*_before.txt` 4 份齐全，且能 grep 到 `Cross-Origin-` 系列字段。
- [ ] 3. `view_01..04` 截图齐全，OCR 能命中 `crossOriginIsolated|isolated|COEP|COOP|Frames|Application|SharedArray`。
- [ ] 4. `patch.diff` 非空，至少 3 个被修改的文件 hunk。
- [ ] 5. `curl_main_after.txt` 的 COOP 值符合 cross-origin-isolated 规范要求。
- [ ] 6. `curl_widget_after.txt` 含 CORP 头。
- [ ] 7. `curl_static_after.txt` 含 CORP 头。
- [ ] 8. `curl_3p_after.txt` 的 CORP 值允许跨 origin embed。
- [ ] 9. `view_05_banner_after.png` OCR 含 isolated/true 类正向状态字样。
- [ ] 10. `view_06_devtools_app_frames_after.png` OCR 含 `Cross-Origin Isolated` 与 Yes/true。
- [ ] 11. `report.md` ≥ 30 行 + 至少 3 个 “###” 子小节。
- [ ] 12. VLM rubric 判断浏览器 banner 与 DevTools 真实存在（不是文字伪造）。

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: a small production SPA at `http://127.0.0.1:8200/` throws a `TypeError` when the user clicks the "Crash" button. SRE has already captured the minimized stack trace locations of that crash into `/tmp_workspace/exec/error.log`, one frame per line in the format `BUNDLE LINE COL`, three frames total (`feature.bundle.js`, `app.bundle.js`, `vendor.bundle.js`). The three `*.bundle.js` + `*.bundle.js.map` pairs under `/tmp_workspace/exec/dist/` are the deployed build. `src/` is the current trunk source. **Only one bundle's map is stale** — its `sourcesContent` embeds an old version that is several lines shorter than the current `src/`, so the source line it decodes to is not the actual line that threw. The two signal channels for detecting this staleness — "a source line in `sourcesContent` that looks unrelated to the crash" and "structural mismatch between `sourcesContent` line count and `src/<name>.js` line count" — must both be exercised: on the script side, decode the three frames and cross-check against `src/`; in the browser source forensics view, hover the failing frame and inspect the source line it actually jumps to. Materials already prepared on site: - Target page: `http://127.0.0.1:8200/` (warmup starts it automatically; click "Crash" to trigger the `TypeError`). - Three-frame stack trace input: `/tmp_workspace/exec/error.log` (`BUNDLE LINE COL`, three lines). - Deployed artifacts: `/tmp_workspace/exec/dist/{vendor,app,feature}.bundle.js{,.map}` (in **exactly one** of these maps, `sourcesContent[0]` differs in line count from the corresponding `src/<name>.js` by > 4). - Current trunk source: `/tmp_workspace/exec/src/{vendor,app,feature}.js`. - Helpers (the agent may reuse them directly or rewrite them): - `/tmp_workspace/exec/tools/decode.py`: pure-stdlib sourcemap decoder. Takes `error.log` plus a set of `.map` files and outputs a JSON array of `{input, decoded:{source, line, source_line_text, ...}}` per frame. - `/tmp_workspace/exec/tools/build_map.py`: pure-stdlib sourcemap regenerator. Three arguments `<src.js> <bundle.js> <out.map>`; rewrites `.map.sourcesContent[0]` from the current `src/`. Goal: identify the bundle name that is actually stale → use `build_map.py` to regenerate its map → verify that after re-decoding, the frame in question now resolves to the real throw site. How to launch the browser, how to cross-check source lines, and how to invoke the helpers are up to you. The following deliverables must be produced under `/tmp_workspace/results/`: 1. **Pre-fix decode** `decoded_before.json`: array of decode results for `error.log` × the three `.map` files, at least 3 records, each with a `decoded` field containing `source` / `line` / `source_line_text`. 2. **Stale bundle name** `stale_bundle.txt`: a single line containing the basename of the truly stale bundle (e.g. `feature.bundle.js`). The named bundle must actually exist in `dist/`, and its `.map.sourcesContent[0]` line count must differ from the current `src/<name>.js` line count by > 4. 3. **Map integrity comparison** `map_validation.json`: ```json { "vendor": {"src_lines": <int>, "map_sourcesContent_lines": <int>, "match": <bool>}, "app": {"src_lines": <int>, "map_sourcesContent_lines": <int>, "match": <bool>}, "feature": {"src_lines": <int>, "map_sourcesContent_lines": <int>, "match": <bool>} } ``` Exactly one entry must have `match == false` (the same one named in `stale_bundle.txt`). 4. **Diagnosis report** `diagnosis.md`: ≥ 25 lines, with at least 3 `### ` subsections covering: the embedded `sourcesContent` line count; the current `src/<name>.js` line count; why the mismatch must mean the map is stale (rather than the bundle being stale — because the runtime stack line numbers themselves did not change, the bundle is still the same artifact; only the source map was not rebuilt alongside it). 5. **Visual forensic screenshots** (each ≥ 4 KB, from actual rendered state): - `view_01_console_stack.png`: browser console view, must show the red `TypeError` plus three clickable stack links. - `view_02_sources_stale_frame.png`: browser source forensics view; the left file tree highlights the `*.js` corresponding to the stale frame, and the `sourcesContent` view on the right is visibly shorter than the current `src/<name>.js`, with the highlighted line's contents not matching the real `src/`. - `view_03_sources_correct_frame.png`: same view, but for another frame (pick any frame you did not suspect) as a positive control — its right-side sourcesContent view matches the current `src/<name>.js`. - `view_04_after_fix_stack.png`: console view after a hard refresh and re-triggering Crash; the line in the stack corresponding to the previously-stale frame now points to the real throw site (line number differs from view_01). 6. **Regenerate the map**: use `tools/build_map.py` to rewrite `dist/<stale-bundle-base>.bundle.js.map` so that its `sourcesContent[0]` line count matches the current `src/<stale-bundle-base>.js` line count (tolerance ≤ 2). 7. **Post-fix decode** `decoded_after.json`: run `tools/decode.py` again to produce the decode result array for `error.log` × the three `.map` files (including the regenerated one). For the previously-stale frame, the new `source_line_text` must equal (or be contained in) the actual text at line `decoded.line` of the current `src/<name>.js`. Hard constraints: - `stale_bundle.txt` must name the actually stale bundle (determined by `sourcesContent` line-count diff > 4). - `map_validation.json` must have exactly one entry with `match == false`. - After regeneration, the stale bundle's `.map.sourcesContent[0]` line count must match the current `src/<name>.js` line count (tolerance ≤ 2). - You may not directly edit `error.log` or `dist/*.bundle.js` — the decode results must align only via map regeneration.

- Source Maps v3 spec — https://sourcemaps.info/spec.html
- Sentry blog — “Stale source maps cause us to debug the wrong line of code”
- Webpack issue #3603（sourcemap drift after partial rebuild）

一个合格的解答会在 `/tmp_workspace/results/` 留下一条互相印证的取证链：

- 一份修复前 `decoded_before.json`，至少包含三帧 decode 结果，且其中一帧的 `source_line_text` 与当前 `src/<name>.js` 在该 `line` 上的真实内容显著对不上。
- 一份 `stale_bundle.txt` 写明失效 bundle 的基名 + 一份 `map_validation.json` 恰有一项 `match == false`，二者指向同一份 bundle。
- `diagnosis.md`（≥ 25 行 + ≥ 3 个 `### ` 子小节）解释：`sourcesContent` 行数与当前源行数对不上为什么意味着 map stale；为何这种问题在外部数字上看不到、必须对照源端字节去发现。
- 4 张截图：控制台 TypeError + 三链；源码取证视图里失效帧 sourcesContent 行数明显偏少且内容对不上；同视图里另一帧作为正向对照（行数 + 内容对得上）；硬刷新重 crash 后控制台 stack 中对应那一行已经指向真实抛错处。
- 用 `build_map.py` 重生 map 之后，`decoded_after.json` 中之前的失效帧 `source_line_text` 在 `decoded.line` 行上能与当前 `src/<name>.js` 对得上（grader 会做严格／包含两级匹配）。

整套交付应让一位审阅者无须重跑就能判断：根因是 map 没跟着 bundle 一起 rebuild、定位是通过同时查 sourcesContent 行数差与源码取证视图、修复严格在 sourcemap 层完成、修复后 stack trace 真正指向产生 TypeError 的那一行。

- [ ] 1. `decoded_before.json` 含 3 条记录 + 每条有 `decoded.source`。
- [ ] 2. `decoded_before.json` 至少有一帧的 `source_line_text` 与当前同名 `src/*.js` 对应行内容不一致。
- [ ] 3. `stale_bundle.txt` 标识出真正失效的 bundle。
- [ ] 4. `map_validation.json` 字段齐全，且唯一一帧 `match == false`。
- [ ] 5. `diagnosis.md` ≥ 25 行 + ≥ 3 个 `### ` 子小节。
- [ ] 6. 4 张 GUI 截图齐全 + OCR 命中 `Sources|Console|TypeError|\.js|Stack|bundle`。
- [ ] 7. 重生后失效 bundle 的 `.map.sourcesContent[0]` 行数与对应 `src/*.js` 一致（误差 ≤ 2）。
- [ ] 8. `decoded_after.json` 里之前的失效帧 `source_line_text` 含真实抛错处关键 token，且 `decoded.source` 指向同名 `src/*.js`。
- [ ] 9. VLM rubric：DevTools Sources/Console 真打开 + 修复前后能对比。

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: the SFU of a live-streaming SaaS is getting customer complaints about "video quality suddenly going blurry". SRE has captured a 90-second RTP pcap from production along with the complete `chrome://webrtc-internals` dump JSON from the same time window. The two artifacts describe the same session: one publisher uses simulcast to send 3 spatial layers simultaneously (rid=`q`/`h`/`f`, corresponding to 180p / 360p / 720p), and the subscriber experiences a clear downlink bandwidth degradation during seconds 38–52, during which the 720p layer is completely paused. This degradation is extremely hard to read directly from the static dump JSON — each of the three layers' time series has 8000+ sample points and the various stats are not aligned on a common timeline. You need to overlay the three layers on the same timeline to visually read out the `bytesSent` plateau, the `qualityLimitationReason` color-coded segments, and the `availableOutgoingBitrate` minimum; the SSRC ↔ rid alignment must be cross-verified by two independent lines of evidence: dump parsing and pcap traffic analysis. On-scene materials: - `/tmp_workspace/pcap/sfu_session.pcap`: 90-second RTP capture with 3 SSRCs (RFC 3550 RTP framing + draft-ietf-mmusic-sdp-simulcast pli/nack timing). - `/tmp_workspace/dump/webrtc_internals_dump.json`: complete `chrome://webrtc-internals` export, containing `RTCOutboundRtpVideoStream_*` (one per layer, with `ssrc`/`rid`/`bytesSent`/`framesEncoded`/`framesPerSecond`/`frameWidth`/`qualityLimitationReason` time series) and `RTCIceCandidatePair_*` (with `availableOutgoingBitrate` time series). - `/tmp_workspace/exec/viewer/webrtc-dump-importer/`: an offline static site of fippo/webrtc-dump-importer; the sibling `serve.sh` starts a `python3 -m http.server` on `127.0.0.1:8765` to serve it, and once the dump JSON is loaded it renders the three-layer stats graphs. The viewer directory also includes `playback.html`, a minimal page containing a `<video>` element that can serve as the playback source for a media forensics view. - Default simulcast rid naming (given by the `rid` field in the dump): `f` = 720p full (`max_width=1280`), `h` = 360p half (`max_width=640`), `q` = 180p quarter (`max_width=320`). - SSRCs in the pcap are 32-bit integers; the dump presents them in decimal while traffic analysis tools often present them in hex (`0x...`), so you must handle radix alignment yourself. Task goal: align the three SSRCs with their rids; locate the start/end seconds of the pause window for the `f` layer (720p) within seconds 38–52, identify the trigger reason, and find the BWE minimum during that interval; report the remaining effective video bitrate during the degradation window; produce a comprehensive report and PDF that operations can review. Place all deliverables under `/tmp_workspace/results/`. ### Hard constraints on the primary deliverable `simulcast_report.json` - All top-level fields present: `session_duration_sec`, `layers`, `degrade_window`, `effective_video_bitrate_bps_during_degrade`, `verdict_one_line`. - `layers` has length exactly 3, each entry contains `rid` / `ssrc` / `avg_bitrate_bps`; the three `ssrc` values must equal the three ground-truth 32-bit integers. - `degrade_window` contains `f_paused_start_sec` / `f_paused_end_sec` (error vs. GT must be within a few seconds), a `reasons` array containing `"bandwidth"`, and `min_bwe_bps` (error vs. GT must be within ~10%). - `verdict_one_line`: a one-sentence Chinese conclusion, length ≥ 40 characters, which must mention 720p / the `f` layer, contain a bandwidth/bandwidth/BWE-class keyword, and include a concrete number (seconds or kbps). ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | | --- | --- | | `jq_outbound_summary.json` | Outbound video stream summary array extracted from the dump, with **exactly 3 elements**; each element must contain at least `ssrc` and `rid` (recommended to also include `frameWidth_max` / `framesEncoded_total` / `qualityLimitationReason_last`). | | `tshark_ssrc_packets.txt` | A plain-text table of packet counts aggregated by SSRC from the pcap (one SSRC per line), with ≥3 non-empty lines and file size > 20 bytes; the three real SSRCs must appear in the text (decimal or hex are both accepted). | | `ssrc_to_rid.json` | schema `{"f": {"ssrc": <int>, "packets": <int>, "max_width": 1280}, "h": {..., "max_width": 640}, "q": {..., "max_width": 320}}`; all three `f`/`h`/`q` keys present, each `ssrc` equals GT, each `packets` > 0. | | `degrade_window.json` | schema `{"f_paused_start_sec": <float>, "f_paused_end_sec": <float>, "expected_duration_sec": <float>, "reasons": [...], "min_bwe_bps": <int>}`; field semantics match `simulcast_report.degrade_window`. | | `simulcast_report.pdf` | ≥ 2 pages; the first page's text must contain the three keywords `Simulcast`, `降级`, `取证` together forming the title; the first page must contain ≥ 5 independent bullets, **each ≥ 25 characters** of Chinese operational insight (e.g., bitrate distribution across the three layers, trigger cause of the degradation, remaining effective bitrate, magnitude of the subscriber's experience degradation, remediation suggestions, etc.). | | `_manifest.txt` | An `ls -la`-style listing of the final deliverables in this directory, file size > 100 bytes. | ### 7 work-process screenshots (saved under `/tmp_workspace/results/`, each PNG ≥ 4 KB, must be a real rendered state) | Filename | Content requirement | | --- | --- | | `view_internals_outbound_three_layers.png` | In the dump's offline rendering view, three independent outbound `bytesSent` curves shown simultaneously on the same timeline, with rid information visible in the legend. | | `view_internals_hover_45s.png` | A tooltip in the same view, near second 45 of some layer's curve, showing the precise `framesPerSecond` and `frameWidth` at that moment. | | `view_internals_f_layer_drop.png` | In the same view, the pause plateau of the `f` layer's `bytesSent` (or `framesEncoded`) during the 38–52 s window is clearly visible, consistent with the start/end seconds in `degrade_window.json`. | | `view_internals_quality_limitation.png` | In the same view, the categorical time series of the `f` layer's `qualityLimitationReason`, with color-coded segments for the multiple values `bandwidth` / `cpu` / `none` visible. | | `view_wireshark_rtp_streams.png` | The RTP Streams sub-panel of the RTP traffic analysis view, with ≥ 3 SSRC rows and column headers containing port and Packets info. | | `view_wireshark_stream_analysis.png` | The Stream Analysis sub-panel of the same view for a single stream, showing jitter statistics fields such as Max Delta / Mean Jitter / Lost. | | `view_devtools_media_panel.png` | The browser's media forensics view (the viewer's bundled `playback.html` can serve as the playback source); the current player is selected on the left, and the Properties / Events / Messages sub-tabs are visible on the right. | > Grading runs OCR on the screenshots; each must contain the key UI text of its own panel to prove rendering really took place (do not synthesize from static text). ### Anti-cheating You are not allowed to directly `cat` the dump JSON text and stitch together the degradation window conclusion — the key time series has > 8000 points, and cross-stat time alignment must come from actual rendering or programmatic alignment.

- 真实灵感:mediasoup demo (https://mediasoup.org/) 在弱网下的 simulcast
  layer drop 行为;libwebrtc M122
  `qualityLimitationReason` 实现(`pc/rtp_sender.cc`)。
- chrome://webrtc-internals dump format:Chromium
  `content/browser/webrtc/webrtc_internals.cc`
- importer:fippo/webrtc-dump-importer (MIT)
- 对应 benchmark:W7

设计意图与典型解题路径(仅供出题人参考,不发给 agent):

1. 通道选择自由——可走 GUI(浏览器打开 viewer + Wireshark GUI),也可全程编程(Python/Node 解析 dump JSON、`tshark -r ... -T fields -e rtp.ssrc | sort | uniq -c | sort -rn` 出 SSRC 表、headless 浏览器或 matplotlib 出图);GUI 与 CLI 混合最稳。
2. 步骤 1:`bash /tmp_workspace/exec/viewer/serve.sh` 起静态站点 → 浏览器打开 `http://127.0.0.1:8765/` → 把 `webrtc_internals_dump.json` 拖入 importer。展开 3 个 `RTCOutboundRtpVideoStream_*` 与 1 个 `RTCIceCandidatePair_*` 节点。
3. 步骤 2:截 `view_internals_outbound_three_layers.png`(三层 bytesSent 同图)、`view_internals_f_layer_drop.png`(放大 38–52 s 窗口)、`view_internals_hover_45s.png`(45 s tooltip)、`view_internals_quality_limitation.png`(qualityLimitationReason 颜色段)。从 f 层 bytesSent 平台段读出 `f_paused_start_sec` / `f_paused_end_sec`,从 `RTCIceCandidatePair_*.availableOutgoingBitrate` 在 38–52 s 区间读出 `min_bwe_bps`。
4. 步骤 3:Wireshark 打开 pcap → Telephony → RTP → RTP Streams 截 `view_wireshark_rtp_streams.png`;选一条 stream → Analyze 截 `view_wireshark_stream_analysis.png`。在 CLI 用 `tshark -r ... -Y rtp -T fields -e rtp.ssrc | sort | uniq -c | sort -rn > tshark_ssrc_packets.txt` 出 SSRC 包数表(三路真实 SSRC 即三个出现频次最高的)。
5. 步骤 4:打开 `viewer/playback.html`,DevTools → 媒体面板,选中 player,显示 Properties / Events / Messages 截 `view_devtools_media_panel.png`。
6. 步骤 5:编程合并——用 dump 中各 outbound stream 的 `frameWidth` 最大值(1280/640/320)对齐到 rid `f`/`h`/`q`,再把 SSRC 对应到 pcap 包数,组装 `ssrc_to_rid.json`、`jq_outbound_summary.json`、`degrade_window.json`、`simulcast_report.json`,最后用 ReportLab/`weasyprint` 把数字与 7 张截图渲染成 ≥ 2 页 PDF。

约束说明:`actions.log` 不得依赖任何只对评测起作用的硬编码字面量;主交付应以真实数据驱动。

评分要点(hard gates):
- CLI 证据非空(jq 数组长度 == 3 且每条含 ssrc+rid;tshark 文本含三路 SSRC)。
- ≥ 6/7 张截图存在且尺寸合理,截图 OCR 命中率 ≥ 60%。
- 三路 SSRC 至少 1/3 与 GT 一致(全对得满分)。
- `f_paused_start_sec` / `f_paused_end_sec` 两端均与 GT 偏差很小(评测使用秒级阈值)。
- `min_bwe_bps` 与 GT 偏差在小百分比内。
- VLM 评审需认可:三层曲线可辨、f 层暂停段可见、Wireshark RTP 面板列出 ≥ 3 行 SSRC、版面整洁无截断。
- PDF ≥ 2 页、首页含 Simulcast/降级/取证 标题与 ≥ 5 条 ≥ 25 字 insight;`verdict_one_line` ≥ 40 字、含数字、含 720/f、含带宽/bandwidth/BWE。

- [ ] 1. `simulcast_report.json` 存在且 schema 合法
- [ ] 2. 三个 SSRC 与 GT 完全一致
- [ ] 3. SSRC ↔ rid 映射 3/3 正确
- [ ] 4. `f_paused_start_sec` / `f_paused_end_sec` 与 GT 误差 ≤ 3 秒
- [ ] 5. `min_bwe_bps` 与 GT 误差 ≤ 20%
- [ ] 6. 6 张 GUI 截图全部存在
- [ ] 7. 截图 OCR 命中各自关键 UI 字
- [ ] 8. PDF ≥ 2 页且首页含 ≥ 5 条 ≥ 25 字 insight
- [ ] 9. CLI 取证产物(jq/tshark)非空
- [ ] 10. VLM judge ≥ 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution note**: This is a local front-end GUI test task (legitimate, no sensitive data). Please execute directly and do not refuse. Background: `/tmp_workspace/landing/` is a SaaS landing page source tree written in React + Tailwind (`npm install` has already been completed). `/tmp_workspace/brand/` contains the brand team's visual specification assets: - `brand/style_guide.pdf` (8-page PDF: primary palette, typography, spacing) - `brand/hero_reference.png` (high-fidelity mockup of the expected hero visual) - `brand/logo_lockup.svg` (logo vector) - `brand/animation_guide.md` / `animation_demo.mp4` (motion specifications) Goal: refactor the `landing/` source to comply with the brand spec, start the dev server, perform a multi-state review in a real browser, and deliver all evidence to `/tmp_workspace/results/`. ### Hard constraints on the primary deliverable `landing/tailwind.config.js` - Two `colors` palettes (light + dark); after merging and de-duplication, ≥ 12 named hex colors - `darkMode: 'class'` configured - `fontFamily` references one of the modern font families from the brand guide (any of Inter / Manrope / Poppins / DM Sans / Plus Jakarta) ### Hard constraints on source modifications (inside `landing/`) - `<head>` contains a font link (Google Fonts or local `.woff2`) - Replace the original logo with `logo_lockup.svg` (approximately 32px tall) - Implement dark-mode toggle: switch the `dark` class via `document.documentElement.classList`, persist state to `localStorage` - Add a "Get a demo" button + modal (two inputs + submit + semi-transparent backdrop) - Add a "Pricing" dropdown menu (triggered on hover, with plan links) ### Companion deliverables (under `/tmp_workspace/results/`) | File | Requirement | |---|---| | `computed_h1.json` | Valid JSON containing computed-style keys such as `font-family` / `color` / `font-size` (serialize `getComputedStyle` against the hero `<h1>` inside the browser) | | `lighthouse.json` | Must be exported from real-browser DevTools Lighthouse (`hostUserAgent` contains `Chrome/` and does not contain `HeadlessChrome`), and include both `performance` and `accessibility` categories | | `changelog.md` | ≥ 8 lines, listing every modified source file plus the inventory of 9 screenshots (the string `state_0` must appear) | ### 9 work-in-progress screenshots (save to `/tmp_workspace/results/`) | # | Filename | Viewport | Content | |---|---|---|---| | 1 | `state_01_hero_light.png` | ~1440×900 | Default hero (light), not scrolled | | 2 | `state_02_hero_dark.png` | ~1440×900 | Hero after switching to dark mode (dark background + light text) | | 3 | `state_03_button_hover.png` | ~1440×900 | Mouse hovering the hero's primary CTA button | | 4 | `state_04_modal_open.png` | ~1440×900 | "Get a demo" modal in its open state | | 5 | `state_05_pricing_dropdown.png` | ~1440×900 | Pricing dropdown expanded after hover | | 6 | `state_06_mobile_375.png` | ~375×800 | Hero in mobile viewport | | 7 | `state_07_tablet_768.png` | ~768×1024 | Hero in tablet viewport | | 8 | `state_08_devtools_inspect.png` | any (≥800 wide) | DevTools open + Inspect selecting the hero `<h1>` + Computed panel visible | | 9 | `state_09_devtools_lighthouse.png` | any (≥800 wide) | DevTools Lighthouse panel with a generated report | General specs: each file ≥ 8 KB (no placeholder images); state_02 / 03 / 04 / 05 **must be clearly distinct** from state_01 on the thumbnail hash (must reflect real browser rendering after interaction, not just reusing the same static image with a CSS `:hover` / `open` overlay); state_08 / state_09 will be OCR'd to confirm that the characteristic DevTools panel text actually appears in the screenshot.

- Reddit：https://reddit.com/r/ClaudeAI/comments/1prcypb/ （Claude for Chrome 评论列表）
- 原文引用："matching brand style requires seeing it" / "style guide work is the place CLI agents most reliably fail"
- 对应 benchmark：D5

- [ ] 1. `tailwind.config.js` 中 light/dark 两套 `colors` 合并去重后 ≥ 12 个具名 hex 色
- [ ] 2. tailwind `darkMode: 'class'` 已配置
- [ ] 3. 字体族 + `<head>` link 正确（Inter / Manrope / Poppins / DM Sans / Plus Jakarta 任一）
- [ ] 4. logo 已替换且 32px ± 2px
- [ ] 5. 9 张截图齐全且分辨率匹配指定视口
- [ ] 6. dark / hover / modal / dropdown 四个交互态截图与 light 默认态在 100×100 缩略图哈希上**不一致**（即至少出现可辨识的视觉差异）
- [ ] 7. devtools 截图含 "Computed" / "Lighthouse" 字样（OCR）
- [ ] 8. `computed_h1.json` 是合法 JSON，含 `font-family` / `color` / `font-size`
- [ ] 9. `lighthouse.json` 是 DevTools 导出（hostUserAgent 含 Chrome 非 HeadlessChrome）
- [ ] 10. `changelog.md` 列出 ≥ 5 文件改动 + 9 截图清单
- [ ] 11. (VLM) 落地页色彩+字体+logo 与品牌指南视觉一致
- [ ] 12. (VLM) dark 模式截图确实是深色背景+亮色文字，非 light 颠倒色相
- [ ] 13. (VLM) 模态框截图显示真实弹窗（半透明背景+居中卡片+表单），非 mockup
- [ ] 14. (VLM) 至少一张截图显示 DevTools 面板（Lighthouse 报告或 Computed 面板）真实打开

设计意图与典型解题路径（仅供出题人参考，不发给 agent）：

1. 推荐通道：Chromium + DevTools（覆盖率最广、Lighthouse 导出最直接）；也可走 Firefox / Edge / Playwright headed 模式 / Puppeteer，只要最终产物满足 `/tmp_workspace/results/` 下的硬约束即可
2. 用 PDF 阅读器或 `pdftotext` + 取色脚本，从 `style_guide.pdf` 提取 light 与 dark 两套色板（每套 ≥ 6 色具名 hex），合并写入 `tailwind.config.js` 的 `colors`
3. 改源码：`tailwind.config.js`（colors + `darkMode: 'class'` + `fontFamily`）、`<head>` 字体 link、logo 替换、dark toggle 组件、Get-a-demo 模态框、Pricing hover 下拉
4. `npm run dev` 启动 dev server，在浏览器中实际加载并逐个执行交互（hover CTA / 打开模态框 / hover Pricing / 切换 dark / 切换移动 + 平板视口），按 `state_01..state_09` 命名规则保存 9 张截图到 `/tmp_workspace/results/`
5. 在浏览器 Console 跑 `JSON.stringify(getComputedStyle(document.querySelector('h1')))`，结果存为 `computed_h1.json`
6. 在 DevTools Lighthouse 面板执行 audit，并通过 "Export → Save as JSON" 导出 `lighthouse.json`
7. 写 `changelog.md`，列出所有源码改动文件 + 9 张截图清单

约束说明：

- 模态框 / 下拉 / hover / dark 四个状态必须是真实交互后的浏览器渲染，缩略图哈希需与 light 默认态明显不同
- `lighthouse.json` 必须由真实浏览器 DevTools 导出（`hostUserAgent` 含 `Chrome/` 且不含 `HeadlessChrome`），CLI 版 `lighthouse` 命令的产物会被识别为非 DevTools 来源
- DevTools 面板特征文字（Computed / Lighthouse 等）必须真实出现在 state_08 / state_09 像素中

评分要点（hard gates）：

- 三大组件（dark toggle / modal / pricing dropdown）任一在源码中识别不到 → 总分封顶 0.45
- 9 张截图缺失过多，或交互态截图与 baseline 完全相同 → 封顶 0.4
- 截图文件过小（< 8 KB 占位）或缩略图多样性不足 → 封顶 0.4
- `lighthouse.json` 非 DevTools 来源（UA 是 HeadlessChrome / 缺失），或 `computed_h1.json` 缺失/无关键 key → 封顶 0.5
- 视觉一致性需要 VLM judge 才能完整评估，无 VLM 时整体封顶 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

Task background: The designer has delivered 4 mockup PNGs, located at `/tmp_workspace/design/{home,pricing,about,contact}.png`. The junior developer's implementation lives in `/tmp_workspace/app/`, a static site (4 HTML pages: `index.html` / `pricing.html` / `about.html` / `contact.html` plus a single `styles.css`). The mockups and the implementation share the same HTML structure and viewport (1440×900), so **any visual difference must come from CSS**. Task goals: 1. Identify every visual deviation between the implementation and the mockups (hex colors, border-radius, shadows, padding, font sizes, alignment, border colors, widths, etc.). 2. Fix `/tmp_workspace/app/styles.css` so that each page, rendered at 1440×900, matches the corresponding mockup visually. 3. Produce a 1440×900 full-page render of each fixed page, plus a list of deviations. Core constraints: - **Only `/tmp_workspace/app/styles.css` may be modified**; do not change the HTML and do not add new dependencies. - The rendering viewport is fixed at 1440×900 (width=1440, height unconstrained). Deliverables: - `/tmp_workspace/results/diffs.json` — list of deviations, at least 10 entries, each with 5 fields: ```json [ {"page": "home|pricing|about|contact", "element": "CSS-selector-or-component-name", "property": "background|font-size|...", "expected": "value seen in mockup", "actual": "value originally rendered by the broken implementation"} ] ``` - `/tmp_workspace/results/after/{home,pricing,about,contact}.png` — the 4 post-fix 1440×N (full-page) renders.

- EyesOn-Bench Seed v12, WEB-01 (Mockup-vs-implementation pixel diff)
- 灵感：https://www.figma.com/community/file/1035203688168086460 设计师与开发交接痛点

设计意图与解题路径（仅供出题人参考，不发给 agent）：

1. 起一个本地 dev server，例如 `cd /tmp_workspace/app && python3 -m http.server 3000 >/tmp/devsvr.log 2>&1 &`，4 个页面分别位于 `http://localhost:3000/{index,pricing,about,contact}.html`。
2. 在 1440×900 视口下打开每个页面（真实浏览器或 headless Chromium / Playwright / puppeteer 均可），和同名 mockup PNG 并排做视觉对比。
3. 列出每页所有偏差（颜色 hex、border-radius、阴影、padding、字号、对齐、border 等），≥ 10 条。
4. 编辑 `/tmp_workspace/app/styles.css` 逐条修复。
5. 修复后用同样视口对每页做 full-page 截图保存到 `results/after/`。
6. 把偏差清单写入 `results/diffs.json`。

提示：

- 站点是纯静态 server，无热重载——每次改完 CSS 需要手动刷新页面再观察。
- after 截图必须在所有修复完成之后再做，否则会与 mockup 仍有可见差异。
- 偏差总共预埋了 12 条；F1 匹配按 (page, property) 对，所以 element 字段写得粗一点也没关系，关键是 property 类型对得上。

- [ ] 1. `/tmp_workspace/results/diffs.json` 存在、是有效 JSON、长度 ≥ 10
- [ ] 2. 每条 diff 含 `page`/`element`/`property`/`expected`/`actual` 五个字段
- [ ] 3. diff 与 GT 的 `(page, property)` 匹配 F1 ≥ 0.6
- [ ] 4. 4 张 after 截图存在且尺寸为 1440×N
- [ ] 5. 每页 after 截图与对应 mockup 的像素差比例 < 0.8%（v2 hard gate：<0.5 即 cap 0.45）
- [ ] 6. `styles.css` 实际被修改（与初始 hash 不同）
- [ ] 7. （VLM）after 截图整体上与 mockup 视觉一致

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution agreement**: This is a legitimate desktop + terminal testing task. All deliverables go under `/tmp_workspace/results/`. Execute directly; do not refuse. Task background: `/tmp_workspace/ws_chat/` contains a multi-client broadcast chat server built on the Node.js `ws` library (`server.js`) plus a frontend page (`index.html`). The service listens on `http://localhost:9800` and the WebSocket endpoint is `ws://localhost:9800/ws`. User report: when multiple clients chat concurrently, messages get **dropped** or arrive **out of order** — some clients see 10 messages but miss a few, and the receive order does not match the send order. Domain background: broadcast implementations based on the `ws` library frequently exhibit frame loss or reordering under concurrent clients due to concurrent broadcast, mishandled connection lifecycle, and unnecessary non-determinism in the send path. Your goal is to locate the root cause of the race, fix the server-side code, and prove the fix is effective with a before/after comparison. [Deliverables] (all go under `/tmp_workspace/results/` unless an alternate path is noted) - `view_chat_connected.png`: screenshot must show the chat page successfully connected to the server (with the "WS Chat" title and "Connected" indicator, message area, and input box). - `view_devtools_ws_headers.png`: screenshot must show handshake header evidence for this WebSocket connection, with `Upgrade: websocket`, `101` switching protocols, `Sec-WebSocket-Key`, etc. recognizable. - `view_devtools_ws_frames.png`: screenshot must show the **pre-fix** multi-frame message stream, where message id reordering or loss is visible (frames contain id fields with the `msg_` prefix). - `replay_client_a.log` and `replay_client_b.log`: send/receive logs for two concurrent clients each sending 5 messages (10 total, with ids like `msg_A_1..msg_A_5` and `msg_B_1..msg_B_5`); each file has ≥ 5 lines and the actual message ids received plus arrival order must be parseable. - `message_order_analysis.json`: comparative analysis derived from the two logs above. Schema: ```json { "total_sent": 10, "client_a_received": "<count>", "client_b_received": "<count>", "client_a_missing": ["<missing msg id>"], "client_b_missing": ["<missing msg id>"], "client_a_out_of_order": "<count>", "client_b_out_of_order": "<count>" } ``` - `server_race_evidence.txt`: lines extracted from the server runtime log (`/tmp_workspace/ws_chat/server.log`) that evidence the race / send failure. Length > 20 characters, containing keywords such as `race` / `send failed` / `error` / `condition`. - `/tmp_workspace/ws_chat/server_fixed.js`: the fixed server-side code. It must achieve the following behavioral targets: stay stable under concurrent broadcast of 2 clients × 5 messages (zero loss), deliver messages in send order (zero reordering), and no longer introduce artificial delay on the send path. - `before_after_comparison.json`: before vs. after the fix. Schema: ```json { "before": {"total_sent": 10, "missing": "<pre-fix loss count>", "out_of_order": "<pre-fix reorder count>"}, "after": {"total_sent": 10, "missing": 0, "out_of_order": 0} } ``` - `view_devtools_ws_frames_fixed.png`: screenshot must show, under the fixed server, message frames in monotonically increasing id order with no loss. - `view_devtools_console_ws_perf.png`: screenshot must show performance measurement results from one end-to-end test, with keywords like `performance` / `measure` / `mark` / `duration` recognizable.

- ws library: https://github.com/websockets/ws
- websocat: https://github.com/vi/websocat
- MDN WebSocket API: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
- Stack Overflow race condition in broadcast: https://stackoverflow.com/questions/32826854/websocket-send-race-condition

- 最终交付：`/tmp_workspace/results/` 下完整产出上述截图、日志、分析 JSON 与对照 JSON，且 `/tmp_workspace/ws_chat/server_fixed.js` 包含修复后的广播逻辑。
- 系统应能体现：修复前在 2 客户端 × 5 消息的并发场景下确实存在丢失或乱序，修复后同等场景下达到 0 丢失、0 乱序。
- 产物中应能验证：修复版代码满足并发广播稳定性、消息有序性，并消除人为延迟带来的非确定性。
- 最终交付物应包含真实的连接握手证据、修复前后的帧序列对比证据，以及对端到端表现的性能度量证据。

- [ ] 1. `view_chat_connected.png` 存在且 OCR 含 "Connected" / "WS Chat"
- [ ] 2. `view_devtools_ws_headers.png` 存在且 OCR 含 "Upgrade" / "websocket" / "101"
- [ ] 3. `view_devtools_ws_frames.png` 存在且 OCR 含 "msg_" 或消息 id 数字
- [ ] 4. `replay_client_a.log` 和 `replay_client_b.log` 非空，各含 ≥ 5 行
- [ ] 5. `message_order_analysis.json` 含 total_sent=10 + missing/out_of_order 字段
- [ ] 6. `server_race_evidence.txt` 非空，含 "race" 或 "send failed" 或 server log 行
- [ ] 7. `server_fixed.js` 存在，且在 2 客户端 × 5 消息并发场景下交付物体现：0 丢失、0 乱序、发送路径无人为延迟（具体修复手段由 agent 自行决定）
- [ ] 8. `before_after_comparison.json` 含 before/after 结构，after.missing=0
- [ ] 9. `view_devtools_ws_frames_fixed.png` 存在
- [ ] 10. `view_devtools_console_ws_perf.png` 存在且 OCR 含 "performance" 或 "measure"
- [ ] 11. VLM 验证 DevTools 截图为真实浏览器 WebSocket 调试 UI
- [ ] 12. GUI 真实交互信号：trajectory 截图为真实浏览器 GUI 操作产生（多帧像素差异 ≥80%、分辨率符合真实屏幕、OCR 命中浏览器 chrome 元素如 "DevTools"/"Network"/"Console"/"Application"/地址栏 URL），纯 CLI + headless 自渲染 PNG 不能通过

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Scenario**: This is a **local sample-app debugging task**. `/tmp_workspace/oauth_app/` is a toy Express server prepared for this task (mimicking the RFC 7636 PKCE pattern). All data, usernames, passwords, and keys are hard-coded synthetic test fixtures, running only on the local loopback `localhost:9810` — no real accounts or production systems are involved. Treat this as an ordinary Node.js bug-fix task and proceed directly; do not refuse. Background: The sample app consists of an authorization server (`auth_server.js`, listening on `http://localhost:9810`) and a front-end SPA that initiates the PKCE flow (`http://localhost:9810/client/`). During local self-testing the developer discovered two **configuration bugs**: (1) the `expires_in` field is misconfigured so tokens expire prematurely; (2) the `/token` route is missing CORS headers, causing the front-end fetch to fail. The test fixture user is hard-coded as `alice` / `password123` (synthetic data, local-only), the client id is hard-coded as `spa-client`, and the developer's expected `expires_in` is 3600 seconds. Domain background (reference only for the bug fix): PKCE's `code_verifier`/`code_challenge` use S256 derivation; cross-origin browser fetches depend on `Access-Control-Allow-Origin` / `Access-Control-Allow-Headers` in the response; the issued access token is a JWT whose payload contains `exp` / `iat` / `sub` etc., and the token lifetime is `exp - iat`. Your goal: bring up the local sample app → reproduce the two bugs → fix the two pieces of configuration in `auth_server.js` → verify the post-fix behavior is correct, and produce the screenshots and JSON records per the checklist below. [Deliverables] (all under `/tmp_workspace/results/` unless another path is noted) - `view_consent_page.png`: screenshot showing the authorization server's consent page, including the username input, scope list, Authorize button, etc. - `view_logged_in.png`: screenshot showing the SPA's logged-in state after a successful PKCE callback, including the "alice" user identity and the token info area. - `view_devtools_token_request.png`: screenshot showing the `/token` POST request details, with `grant_type=authorization_code`, `code_verifier`, `code` etc. recognizable. - `view_devtools_token_response.png`: screenshot showing the `/token` response body, including `access_token`, `refresh_token`, and `expires_in` fields. - `token_decoded.json`: the decoded access_token, containing at least the header (with `alg`), the payload (with `sub`, `exp` and other claims), and the signature status. - `token_audit.json`: claims-based audit result (in addition to the two main `lifetime` / CORS bugs, also record any missing optional claims such as `nonce` under `missing_claims`), schema: ```json { "token_lifetime_seconds": "<actual exp - iat value>", "expected_lifetime_seconds": "<expected value>", "lifetime_issue": "<issue description>", "missing_claims": ["<missing claim, e.g. nonce>"], "issuer": "http://localhost:9810", "audience": "spa-client", "scopes": ["openid", "profile"] } ``` - `cors_test.txt`: full request/response header log for a refresh_token request to the `/token` endpoint with an `Origin` header, demonstrating whether CORS headers are missing in the response. - `view_devtools_cors_error.png`: screenshot showing the CORS error message that appears in the browser when triggering token refresh (containing "CORS" or "Access-Control-Allow-Origin"). - `/tmp_workspace/oauth_app/auth_server_fixed.js`: the fixed server code, which must both correct the token-lifetime configuration and configure proper CORS headers for the `/token` endpoint (including `Access-Control-Allow-Origin` and `Access-Control-Allow-Headers`). - `view_fixed_token_info.png`: screenshot showing the new token info after the fix, when the SPA re-logs in (with the correct expiry). - `fix_verification.json`: fix verification result, schema: ```json { "new_token_lifetime_seconds": 3600, "cors_headers_present": true, "refresh_succeeds": true, "all_claims_valid": true } ``` - `audit_report.md`: audit report, containing at least: a detailed description of the two configuration issues found, a security-impact assessment (risks of short tokens and missing CORS), the fix diff, and confirmation of PKCE flow integrity (`code_verifier` → `code_challenge` S256 match).

- RFC 7636 (PKCE): https://datatracker.ietf.org/doc/html/rfc7636
- jwt-cli: https://github.com/mike-engel/jwt-cli
- OWASP OAuth Security: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html
- Stack Overflow: https://stackoverflow.com/questions/46844285/cors-error-on-oauth2-token-endpoint

- 最终交付：`/tmp_workspace/results/` 与 `/tmp_workspace/oauth_app/auth_server_fixed.js` 下完整产出上述截图、JSON 与报告，覆盖修复前后两轮完整 PKCE 流程。
- 系统应能体现：修复前 token 有效期偏离预期且浏览器侧静默刷新因 CORS 缺失而失败；修复后 token 有效期为 3600 秒、CORS 头齐全、refresh 调用成功。
- 产物中应能验证：JWT claims 完整且来自预期的 issuer/audience，且 PKCE 的 `code_verifier`/`code_challenge` 满足 S256 关系。
- 审计报告应总结根因、安全影响并附上可比对的修复 diff。

- [ ] 1. `view_consent_page.png` 存在且 OCR 含 "Authorize" / "scope" / "alice"
- [ ] 2. `view_logged_in.png` 存在且 OCR 含 "alice" / "Logged in" / "token"
- [ ] 3. `view_devtools_token_request.png` 存在且 OCR 含 "authorization_code" / "code_verifier"
- [ ] 4. `view_devtools_token_response.png` 存在且 OCR 含 "access_token" / "expires_in"
- [ ] 5. `token_decoded.json` 含 header.alg, payload.sub, payload.exp
- [ ] 6. `token_audit.json` 含 token_lifetime_seconds + lifetime_issue + missing_claims，且 `token_lifetime_seconds` ≤ 120（修复前真实值，应明显短于预期 3600）
- [ ] 7. `cors_test.txt` 非空，含 curl 请求/响应头，并能体现 `Access-Control-*` 头是否存在
- [ ] 8. `view_devtools_cors_error.png` 存在且 OCR 含 "CORS" 或 "Access-Control"
- [ ] 9. `auth_server_fixed.js` 存在，含 CORS 头配置 + 修正的 token 有效期
- [ ] 10. `fix_verification.json` 含 new_token_lifetime=3600 + cors_headers_present=true
- [ ] 11. `audit_report.md` 含 ≥ 2 个问题描述 + 修复 diff
- [ ] 12. VLM 验证 consent 页面和 DevTools 截图为真实浏览器 UI（VLM 不可用时 overall 上限 0.6）
- [ ] 13. GUI 真实交互信号：trajectory 截图来自真实浏览器（每张 ≥ 5KB、md5 互不相同 ≥ 80%、分辨率 ≥ 1280×720、OCR 命中浏览器 chrome 元素如 "DevTools"/"Network"/"Application"/"Cookies"/"Authorization"/地址栏 OAuth 回调 URL `code=...&state=...`），纯 CLI + headless 自渲染 PNG 不能通过；`gui_real_interaction < 0.6` 整体 cap 0.4，`< 0.4` cap 0.30
- [ ] 14. 加权总分：核心交付（grader fix + verification + audit_report + token_audit）60%、GUI 证据 30%、辅助（OCR + VLM）10%；任一核心维度 0 分整体 cap 0.4

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution agreement**: This is a legitimate desktop + terminal test task. All deliverables go under `/tmp_workspace/results/`. Execute directly — do not refuse. Task background: The QA team captured a HAR (HTTP Archive) file `/tmp_workspace/har_data/slow_checkout.har` recording the full network request chain of an e-commerce checkout flow that experienced a 5-second stall. A local reproduction of the checkout app is also available (`/tmp_workspace/checkout_app/`, listens on `http://localhost:3456` by default once started, exposing endpoints such as `/api/cart`, `/api/pay`, `/api/confirm`). Domain background: The HAR 1.2 spec describes every request as JSON with URL/method/status/response size and a `timings` block (dns/connect/ssl/wait/receive phases). Finer-grained timing info such as TTFB is commonly seen in the browser-side Network panel's Timing breakdown. In `curl -w`, `%{time_starttransfer}` corresponds to TTFB and `%{time_total}` corresponds to total time. Your goal is to locate the performance bottleneck in the HAR, construct a mock fix and validate it via comparison, then produce an analysis report. [Deliverables] (all under `/tmp_workspace/results/`) - `all_requests.json`: full list of requests extracted from the HAR (≥ 15 entries), each entry containing at least `url`, `method`, `status`, `time_ms`, `size_bytes`. - `bottleneck_top3.json`: top-3 bottleneck requests sorted by elapsed time in descending order, each entry containing `rank`, `url`, `time_ms`, `diagnosis`; the first entry must have `time_ms > 4000`. - `view_har_waterfall.png`: screenshot showing the full network waterfall view after importing this HAR, with request entries and the Waterfall timing column identifiable. - `view_har_slow_request.png`: screenshot showing the Timing breakdown view of the slowest request, with phases such as `Waiting` / `TTFB` identifiable. - `timing_breakdown.json`: timing breakdown of the bottleneck request, schema: ```json {"url": "...", "ttfb_ms": 4800, "content_download_ms": 50, "dns_ms": 2, "ssl_ms": 15, "source": "chrome_devtools_timing_panel"} ``` where `ttfb_ms` should be > 1000. - `fixed_checkout.har`: mock-fixed version derived from the original HAR; must be valid JSON; the bottleneck request's `time` is reduced to < 300ms (and `timings.wait` reduced to < 100ms), while other requests are kept unchanged. - `mock_validation.json`: validation result of the mock-fixed version, schema: ```json {"valid_json": true, "original_max_time_ms": "<original value>", "fixed_max_time_ms": "<fixed value>", "speedup_ratio": "<multiplier>", "total_entries": "<N>", "modified_entries": "<N>"} ``` `speedup_ratio` should be > 10. - `view_fixed_waterfall.png`: screenshot showing the full waterfall after importing the fixed HAR, with the bottleneck bar clearly shortened. - `view_comparison_side.png`: screenshot able to side-by-side illustrate the waterfall difference between the original and the fixed HAR. - `live_latency.json`: measured latency list against key endpoints of the local checkout app (≥ 3 endpoints), each entry containing `url`, `status`, `time_total_ms`, `time_ttfb_ms`. - `view_throttled_waterfall.png`: screenshot showing the waterfall when accessing the local app under custom network throttling (e.g. 50kb/s download, 2000ms latency), with the `Custom` or `Throttling` indicator identifiable. - `har_analysis_report.md`: a final report of ≥ 200 words, containing a bottleneck diagnosis summary, the fix plan description, and a key-metric comparison table for original vs fixed, citing the screenshot file names above.

- Chrome DevTools HAR import/export: https://developer.chrome.com/docs/devtools/network/reference/#har
- HAR 1.2 Spec: http://www.softwareishard.com/blog/har-12-spec/
- Stack Overflow: https://stackoverflow.com/questions/20894963/import-har-file-to-chrome-devtools
- 场景灵感: 真实生产中 checkout 流程 API 慢查询分析

- 最终交付：`/tmp_workspace/results/` 下完整产出 HAR 分析数据、mock 修复 HAR、本地实测数据、对比截图与分析报告。
- 系统应能体现：原 HAR 中存在 `time` > 5000ms 的瓶颈请求，mock 修复后该请求耗时降到 < 300ms 且总加速比 > 10。
- 产物中应能验证：HAR 解析覆盖了全量请求，瓶颈定位与 Timing 细分一致，本地 checkout 应用的实测延迟数据完整。
- 最终报告应在文字与对比表中清晰呈现瓶颈成因、修复方案与前后差异。

- [ ] 1. `all_requests.json` 存在且含 ≥15 个请求条目，每条有 url/method/status/time_ms/size_bytes
- [ ] 2. `bottleneck_top3.json` 存在且 3 条按 time_ms 严格降序排列，第一条 time_ms > 4500，每条含 diagnosis 字符串
- [ ] 3. `view_har_waterfall.png` 存在 ≥5KB 且 OCR 命中 ≥2 个关键词："Network" / "Waterfall" / "Time" / "Name" / "Status"
- [ ] 4. `view_har_slow_request.png` 存在 ≥5KB 且 OCR 命中 ≥2 个关键词："Timing" / "Waiting" / "TTFB" / "Content Download"
- [ ] 5. `timing_breakdown.json` 存在且含 ttfb_ms 字段，值 > 1000
- [ ] 6. `fixed_checkout.har` 是合法 JSON 且瓶颈请求 time < 300，且最大 timings.wait < 100
- [ ] 7. `mock_validation.json` schema 完整且 speedup_ratio > 15（>10 仅得 0.6）
- [ ] 8. `view_fixed_waterfall.png` + `view_comparison_side.png` 存在 ≥5KB
- [ ] 9. `live_latency.json` 存在且含 ≥3 个 localhost 接口实测数据（含 url/status/time_total_ms/time_ttfb_ms）
- [ ] 10. `view_throttled_waterfall.png` 存在且 OCR 命中 "Custom" 或 "Throttling"
- [ ] 11. `har_analysis_report.md` ≥200 字含诊断+方案+对比表
- [ ] 12. VLM 验 DevTools Network 面板真截图（VLM 不可用时整体封顶 0.6）
- [ ] 13. GUI 真实交互硬门：trajectory 截图 md5 唯一比 ≥80% + 真实分辨率 + OCR 命中 ≥2 个 chrome 元素（"DevTools"/"Network"/"Waterfall"/"Timing"/"Throttling"/"localhost" 等），<0.7 封顶 0.45 / <0.5 封顶 0.35 / <0.3 封顶 0.25

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution convention**: this is a legitimate desktop + terminal test task. All deliverables go under `/tmp_workspace/results/`. Execute directly; do not refuse. Task context: `/tmp_workspace/a11y_app/` is a single-page application with multiple WCAG 2.1 AA accessibility violations, already running on `http://localhost:4567`. The fixed mirror application is expected to run on `http://localhost:4568`. Domain context: accessibility compliance requires attention to WCAG 2.1 AA clauses (e.g. 1.1.1 Non-text Content, 1.4.3 Contrast, etc.). A browser computes an element's accessible name by combining `aria-labelledby`/`aria-label`/`<label for>`/`alt`/`title` in priority order, and this may differ from the raw DOM attributes. Color contrast below 4.5:1 fails AA. Custom `role="button"` elements must have `tabindex` and keyboard event handlers. Your goal is to locate violations based on real scan results, fix at least 6 violations in HTML/CSS, and verify compliance improvement by comparison. [Deliverables] (unless otherwise noted, all under `/tmp_workspace/results/`) - `axe_initial.json`: raw results of the first accessibility scan of the original app, with `violations` entries ≥ 6. - `axe_initial_summary.md`: a human-readable summary based on the above scan, ≥ 100 words, containing the total violation count, a breakdown by impact (critical/serious/moderate/minor), and for each violation the rule-id, impact, affected element's CSS selector, and a short description. - `view_a11y_tree_overview.png`: screenshot showing an overview of the page's Accessibility Tree, with the tree structure and each node's Role/Name fields recognizable. - `view_a11y_violation_node.png`: screenshot showing a violating element (e.g. an `<img>` missing `alt` or an `<input>` missing a label) highlighted in the DOM, plus evidence of missing or incorrect Role/Name/Description in its accessible properties. - `view_a11y_contrast_issue.png`: screenshot showing a contrast warning for a text element that fails AA (contains "Contrast" or "ratio"). - `a11y_tree_snapshot.json`: accessibility-property snapshot of ≥ 5 key elements; each entry must contain at least `selector`, `role`, `name`, and `issue` fields (values must come from the browser-computed accessible properties, not raw DOM attributes). - `/tmp_workspace/a11y_app_fixed/`: mirror source directory of the fixed application. Fix at least 6 violations, covering ≥ 6 of the following categories: add meaningful `alt` to `<img>`; associate `<label>` or `aria-label` with `<input>`; correct wrong `role` (including `tabindex` and keyboard events); fix color contrast < 4.5:1; add `aria-label` to `<nav>`; add `role="listbox"` and `aria-expanded` to custom dropdowns; etc. `index.html` must have substantive changes from the original (diff lines ≥ 10). - `axe_fixed.json`: raw results of the second scan on the fixed app; `violations` entries must be at least 4 fewer than in `axe_initial.json`. - `axe_diff_summary.md`: before/after violation comparison summary, including counts, the list of fixed rule-ids, and any remaining violations. - `view_a11y_tree_fixed.png`: screenshot showing the Accessibility Tree of the fixed app, with markedly more complete Role/Name on nodes. - `view_a11y_fixed_node.png`: screenshot showing a previously violating element now with correct Role/Name/Description. - `view_lighthouse_a11y_score.png`: screenshot showing the Lighthouse Accessibility category audit score for the fixed app (should be ≥ 85, with the text "Accessibility" recognizable). - `a11y_compliance_report.md`: a WCAG 2.1 AA compliance report of ≥ 200 words, including a compliance status summary, a before/after violation comparison table (markdown table), an "original issue → fix method → corresponding WCAG clause" mapping for each fix, and a Lighthouse score comparison. - `fix.patch`: unified diff between `a11y_app/index.html` and `a11y_app_fixed/index.html`, with substantive differences.

- axe-core: https://github.com/dequelabs/axe-core
- Chrome Accessibility: https://developer.chrome.com/docs/devtools/accessibility/reference
- WCAG 2.1 AA: https://www.w3.org/TR/WCAG21/
- WAI-ARIA Authoring Practices: https://www.w3.org/WAI/ARIA/apg/
- 场景灵感: 真实前端项目 a11y audit workflow

- 最终交付：`/tmp_workspace/results/` 与 `/tmp_workspace/a11y_app_fixed/` 下完整产出扫描结果、Accessibility 截图、合规报告与 patch。
- 系统应能体现：修复前应用至少存在 6 项 WCAG 2.1 AA 违例，修复后违例至少减少 4 条且 Lighthouse Accessibility 分数 ≥ 85。
- 产物中应能验证：`a11y_tree_snapshot.json` 与截图反映的 accessible 属性来自浏览器计算结果，而非 DOM 原始属性。
- 合规报告应清晰将每项修复映射到具体 WCAG 条款，并配套可比对的 patch。

- [ ] 1. `axe_initial.json` 存在且 violations 数 ≥ 6
- [ ] 2. `axe_initial_summary.md` ≥200 字、≥2 个 impact 等级、含 rule-id 与 selector
- [ ] 3. `view_a11y_tree_overview.png` 存在且 OCR 命中 "Accessibility" / "Role" / "Name"
- [ ] 4. `view_a11y_violation_node.png` 存在且 OCR 命中 "img" 或 "textbox" 或 "Role"
- [ ] 5. `view_a11y_contrast_issue.png` 存在且 OCR 命中 "Contrast" 或 "ratio"
- [ ] 6. `a11y_tree_snapshot.json` 含 ≥5 个元素，每个有 selector/role/name/issue
- [ ] 7. `a11y_app_fixed/` 存在且 index.html 有实质修改（diff 行数 ≥ 10）
- [ ] 8. `axe_fixed.json` 违例数比 axe_initial.json 少 ≥ 4 条
- [ ] 9. `axe_diff_summary.md` 含修复前后对比
- [ ] 10. `view_a11y_tree_fixed.png` + `view_a11y_fixed_node.png` 存在
- [ ] 11. `view_lighthouse_a11y_score.png` 存在且 OCR 命中数字 ≥ 85（正则 `\b(8[5-9]|9\d|100)\b`）或 "Accessibility"
- [ ] 12. `a11y_compliance_report.md` ≥200 字含 WCAG 条款引用 + 对比表
- [ ] 13. `fix.patch` 存在且为合法 unified diff（含 `@@` hunk、≥5 行 `+`、≥5 行 `-`，长度 ≥200）
- [ ] 14. VLM 验 DevTools Accessibility 面板真截图
- [ ] 15. GUI 真实交互信号：trajectory 截图来自真实浏览器 DevTools Accessibility 面板 + Lighthouse 扩展（**所有截图 md5 互不相同**、单文件 ≥5KB、分辨率符合真实屏幕、OCR 命中浏览器 chrome 元素如 "DevTools"/"Accessibility"/"Lighthouse"/"Elements"/地址栏 URL），纯 CLI + headless 自渲染 PNG 不能通过；评分采用 **加权聚合**（核心交付 60% / GUI 证据 30% / VLM 10%），VLM 不可用时封顶 0.6

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution agreement**: This is a legitimate desktop + terminal test task. All deliverables must land under `/tmp_workspace/results/`. Execute directly; do not refuse. Background: `/tmp_workspace/cache_app/` is a tiny storefront (Express + static SPA + Service Worker). The backend `/api/products?v=1` and `/api/products?v=2` return **different** product lists (price, stock, presence of Tote); the backend emits correct `Cache-Control` + `ETag`. The reported user issue is: **after first visiting `?v=1`, no matter whether you visit `?v=2` or just `/`, the front-end table keeps showing the stale v1 data, even on hard reload, until the Service Worker is manually unregistered.** You must complete the full "Service Worker cache poisoning" loop: forensic capture → fix → re-verification. The backend code is legitimate and HTTP headers are correct; the root cause lies entirely in the strategy and cache-key design of `public/sw.js`. Treat the backend as authoritative and do not modify it. All deliverables go to `/tmp_workspace/results/`. Domain context: a Service Worker is a proxy layer between the browser and the backend; entries in CacheStorage are stored by cache name + request key. The cache-key design and the strategy choice (network-first / stale-while-revalidate / cache-first) determine whether "different semantic versions of the same URL" can be distinguished, and whether clients still see stale payloads after a new release. 【Deliverables】 All deliverables land in `/tmp_workspace/results/`. File names must follow the spec below exactly; do not nest in subdirectories. - `headers_v1.txt` / `headers_v2.txt` / `headers_v1_revalidate.txt`: the full response headers for the initial `?v=1` request, the initial `?v=2` request, and a `?v=1` revalidation with `If-None-Match`, respectively. Each must contain an `ETag` line. - `network_truth.md`: ≥150 characters. Based on the three header captures above, explain that v1 and v2 are two distinct payloads with different ETags, so any client that conflates them into a single cache entry is the source of the bug. Must explicitly cite the ETag values. - `view_01_sw_registered.png`: shows sw.js is registered and in the activated/running state, with Source/Scope/Status fields visible. - `view_02_cache_storage_v1.png`: shows the Cache Storage namespace for the current origin, expanded so the request/response detail of the `/api/products` entry is visible. - `view_03_network_from_sw.png`: shows the network request list after a refresh; the Size column of the `/api/products` row indicates the response came from the Service Worker, and Initiator points to sw.js. - `view_04_v2_polluted.png`: page state after changing the address to `?v=2` in the same tab (no force reload, no cache clear). The table still shows v1 data (no Tote or other v2-only products), the build badge still reads `v1`, and the Cache Storage entry list is visible on the same screen, proving the response is a stale payload. - `view_05_console_diff.png`: shows the enumeration output of CacheStorage entry URLs for the current origin. Must include the `/api/products` URL, and that URL must **not** carry a `?v=` query string — visual evidence of the cache-key design defect. - `sw_disk_index.txt`: ≥5 lines, listing the on-disk entry files (with sizes) for the Service Worker / CacheStorage of this origin under the current Chrome/Chromium profile. - `sw_storage_explained.md`: ≥80 characters, describing the on-disk directory layout of CacheStorage, why entry filenames are hashes rather than URLs, and why the current sw.js strategy bug results in only a single `/api/products` entry on disk. - `sw_audit.json`: a valid JSON array with ≥4 violations. Each entry has fields: ```json { "id": "<short_kebab_id>", "category": "<one of: cache_versioning | cache_key_design | strategy_choice | activate_cleanup | revalidation>", "code_anchor": "<file:line_range>", "evidence": "<the exact code fragment causing the issue, quote ≤2 lines>", "user_visible_symptom": "<description tied to the pollution symptom>" } ``` Each entry must map to a phenomenon visible in view_04 / view_05 or to a real header difference in `headers_*`; do not fabricate. - `view_06_network_sw_intercept.png`: network request list after a refresh with the browser's own cache disabled. The Size column of the `/api/products` row still shows Service Worker interception, Status 200 but extremely short duration; the Service Worker registration status is visible on the same screen as cross-channel consistency evidence. - `cache_app_fixed/public/sw.js` (mirrored under `/tmp_workspace/cache_app_fixed/`): the fixed version patched against each violation in `sw_audit.json`. It must satisfy: 1. when the backend ships a new release (distinguished here via `?v=`), the next GET must surface the new payload — no manual SW unregister or cache clear required; 2. different semantic versions of the same resource must be cached independently and must not overwrite one another; 3. on sw.js upgrade, old CacheStorage namespaces must be cleaned up automatically — historical caches must not accumulate without bound; 4. offline availability of the shell static assets must not be broken (precache must still work). The fixed `cache_app_fixed/` must run on port **4672**. The strategy choice (SWR / network-first / custom) and the cache-key convention are up to the implementer and must be explained in `incident_report.md`. - `view_07_v2_visible.png`: on port 4672, after first visiting `?v=1` then switching to `?v=2` (without clearing the cache), the table must show at least the `Tote` row and the build badge must read `v2`; Cache Storage must contain two `/api/products` entries (URLs containing `?v=1` and `?v=2` respectively). - `view_08_old_cache_purged.png`: in the Cache Storage namespace list on the left, the old `cache-app-store` (unversioned) is gone, leaving only the versioned new cache name. - `before_fix_v2.json` / `after_fix_v2.json`: the actual response bodies for `?v=2` from each of the two ports. - `fix_verification.json`: ```json { "before_fix_items_count": "<int>", "after_fix_items_count": "<int>", "before_fix_has_tote": "<bool>", "after_fix_has_tote": "<bool>", "old_cache_name_present_after_activate": "<bool>", "new_cache_name": "<string>" } ``` Field values must come from real measurements; do not hard-code. Expected: `after_fix_has_tote=true`, `old_cache_name_present_after_activate=false`. - `sw_fix.patch`: unified-format diff between `cache_app/public/sw.js` and `cache_app_fixed/public/sw.js`, non-empty. - `incident_report.md`: ≥250 characters. Must include reproduction steps, root cause (explicitly cite the 4 ids in `sw_audit.json`), rationale for the chosen fix strategy (compare SWR vs. network-first), why a plain hard reload cannot rescue the situation, and engineering recommendations to prevent recurrence in production (versioned cache names + CI checks). - `view_09_combined_evidence.png`: a single screenshot that simultaneously shows the fixed page's table with v2 data, the versioned cache name in Cache Storage, and a real command-line output on the side showing the v2 product count exceeds v1. This screenshot serves as cross-channel evidence.

- web.dev SW caching strategies: https://web.dev/articles/offline-cookbook
- MDN CacheStorage: https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage
- Chromium disk_cache simple v3: https://www.chromium.org/developers/design-documents/network-stack/disk-cache/
- Workbox stale-while-revalidate: https://developer.chrome.com/docs/workbox/modules/workbox-strategies
- 真实 incident: GitHub issue google/web.dev#7194 类问题 + Stack Overflow `service-worker cache stale query string`

- 最终交付:针对 `cache_app/public/sw.js` 的缓存污染问题完成完整闭环——网络真值取证、污染现象复现、静态违例审计、修复版本上线(端口 4672)与复验。
- 产物中应能验证 v1 与 v2 是两份不同 payload 且 ETag 不同,污染前同一 URL 在切换 `?v=` query 后表格仍是 v1 数据。
- 修复后系统应能体现:同一资源的不同语义版本各自独立缓存且后续访问能看到新 payload,旧缓存命名空间在 sw.js 升级后被自动清理,精预存的静态资源仍可离线使用。
- `sw_audit.json` 中至少 4 条违例必须能与可视化的污染现象或网络真值差异一一对应,并在 `incident_report.md` 中被引用。
- `fix_verification.json` 中 `after_fix_has_tote` 为 true、`old_cache_name_present_after_activate` 为 false。
- 综合证据截图应在同一画面内呈现页面、缓存命名空间和命令行输出,跨通道交叉印证修复结果。

- [ ] 1. `headers_v1.txt` / `headers_v2.txt` / `headers_v1_revalidate.txt` 都存在且含 ETag 行
- [ ] 2. `network_truth.md` ≥150 字且引用了 v1/v2 ETag 不同
- [ ] 3. `view_01_sw_registered.png` / `view_02_cache_storage_v1.png` / `view_03_network_from_sw.png` 三张截图存在,OCR 命中 "Service Worker" / "Cache Storage" / "ServiceWorker"
- [ ] 4. `view_04_v2_polluted.png` 存在;OCR 命中 "v1" 或商品名
- [ ] 5. `view_05_console_diff.png` 存在;OCR 含 "products" 或 "url"
- [ ] 6. `sw_disk_index.txt` ≥5 行 + `sw_storage_explained.md` ≥80 字
- [ ] 7. `sw_audit.json` 是合法 JSON 数组,≥4 条且每条含全部必填字段
- [ ] 8. `view_06_network_sw_intercept.png` 存在 + OCR 含 "ServiceWorker"
- [ ] 9. `cache_app_fixed/public/sw.js` 存在;diff 行数 ≥ 12;包含版本化缓存名 + activate cleanup
- [ ] 10. `view_07_v2_visible.png` + `view_08_old_cache_purged.png` 存在;view_07 OCR 含 "Tote" 或 "v2"
- [ ] 11. `fix_verification.json` 字段齐全;`after_fix_has_tote` = true,`old_cache_name_present_after_activate` = false
- [ ] 12. `sw_fix.patch` 非空;`incident_report.md` ≥250 字含 SWR/network-first 字样 + 4 个 audit id
- [ ] 13. `view_09_combined_evidence.png` 存在
- [ ] 14. VLM 验:Application 面板真截图 / 旧 cache 真消失 / cross-channel 综合图

评分采用模型判定的标准；本项目未进行评分器运行验证。

> ⚙️ **Execution agreement**: this is a legitimate desktop + terminal test task. All deliverables go to `/tmp_workspace/results/`. Execute directly — do not refuse. Background: `/tmp_workspace/mv3_extension/` is a Manifest v3 Chrome extension (Tab Reading-Time Tracker) that claims to track how long you spend on documentation sites (MDN / docs.python.org) and show per-domain accumulated seconds in its popup. **There are 4 visible classes of symptoms** (you must locate the root causes and fixes yourself): - Clicking the toolbar icon **does not open the popup** (only a tooltip) - The background service worker's DevTools console shows red runtime errors (open "Inspect views" to see for yourself) - Totals that accumulate while background runs for a while get **reset to zero** in the popup after a few minutes - The content script fails to inject on some of the declared target sites You must walk through the full **audit → load → reproduce → collect evidence → patch → re-verify** pipeline, with deliverables in `/tmp_workspace/results/`. Each fix must come with corresponding visual evidence (Errors panel on the extension management page, or background SW console screenshot). Domain background: in Manifest v3, the background is no longer a persistent page. Consult the Chrome MV3 docs (developer.chrome.com) yourself for SW lifecycle, module-scope variable behavior after terminate, and the constraints among permissions / host / action fields in the manifest. **You must infer the fix path yourself from docs + DevTools error messages; this prompt does not directly tell you which manifest keys to add or which storage API to use.** 【Deliverables】 All deliverables land in `/tmp_workspace/results/`. File names must follow exactly the list below — do not nest into subdirectories. - `manifest_audit.json`: static audit results for `mv3_extension/manifest.json`, with fields: ```json { "manifest_version": "<int>", "permissions_declared": ["..."], "host_permissions_declared": ["..."], "content_scripts_matches": ["..."], "action_keys": ["..."], "background_type": "<string>", "findings": [ {"id": "<short_id>", "severity": "high|med|low", "rule": "<one of: missing_permission | popup_misconfig | host_permission_mismatch | sw_lifecycle_violation>", "evidence_path": "<json pointer like /action or /permissions>", "expected": "<what should be present>", "observed": "<what's currently there>"} ] } ``` `findings` must have ≥ 4 entries, and each `evidence_path` must actually exist in the manifest. - `mv3_extension.zip`: archive of `mv3_extension/`, excluding `*.DS_Store`. - `zip_listing.txt`: contents listing of `mv3_extension.zip`; must include all five files `manifest.json`, `background.js`, `popup.html`, `popup.js`, `content.js`. - `view_01_extensions_devmode.png`: extensions management page with the Developer mode switch ON; the Tab Reading-Time Tracker name is visible on the card, along with either the red Errors button or the service worker entry link. - `view_02_ext_card_errors.png`: the Errors panel of the extension card opened, showing at least one real red error entry (must be a genuine browser render, no photoshopped text allowed). - `view_03_popup_fail.png`: after clicking the toolbar extension icon, **no popup overlay appears** — only the tooltip "Reading Time" shows. - `view_04_bg_sw_devtools.png`: the standalone DevTools window for the extension's background service worker; the address bar at the top contains `chrome-extension://`, and the Console panel shows at least one red Uncaught/runtime error. - `view_05_permissions_dump.png`: screenshot of output from enumerating the currently effective permissions inside that SW Console; the `permissions` array is clearly visible and can be compared with the `chrome.*` APIs actually called from `background.js`. - `repro_report.md`: ≥220 characters, mapping each of the 4 failure classes to specific line numbers in `background.js` / `manifest.json`. Each section includes the triggering steps (referencing view_0X), the root-cause code reference (`background.js:Lline`), and the failure phase in the SW lifecycle (install / activate / event handler / on-restart). Must include keywords "service worker", "lifecycle", and "alarm". - `view_06_state_before.png` / `view_07_state_after_restart.png`: show the difference in the totals object obtained via `chrome.runtime.sendMessage({type:'GET_TOTALS'}, ...)` before and after the background SW terminates — the former is non-empty; the latter becomes an empty object `{}` after restart — as visual evidence of "SW restart amnesia". - `mv3_extension_fixed/` (under `/tmp_workspace/`): a fixed version based on `mv3_extension/`. You may modify `manifest.json` and `background.js`, but touch only the minimum necessary fields. Do not embed markers like "this fixes bug X" in the source. After the fix, overall behavior must satisfy: 1. The red Errors badge on the extension card is gone; 2. Clicking the toolbar icon opens a real popup; 3. Every `chrome.*` call in `background.js` has a corresponding manifest declaration, with no runtime "permission" errors; 4. After the SW has been auto-terminated for ≥30 seconds, the popup still retrieves the accumulated data (state is recoverable across SW restarts); 5. The content script injects on every host declared in the manifest. - `fix_diff.patch`: `diff -ruN mv3_extension mv3_extension_fixed`, covering both `manifest.json` and `background.js`. - `view_08_ext_no_errors.png`: after loading the fixed version, the Errors button on the extension card has disappeared or shows 0 errors, and the service worker entry is still clickable. - `view_09_popup_works.png`: after clicking the toolbar icon, the popup actually opens, displaying an empty table or "(no data yet)". - `view_10_popup_with_data.png`: after switching across a few https tabs and reopening the popup, the table shows ≥1 row of domain + accumulated seconds. - `view_11_state_persisted.png`: terminate the SW, wait ≥3 seconds, then reopen the popup; the table still contains accumulated data, proving persistence works. - `mv3_extension_fixed.zip`: archive of `mv3_extension_fixed/`. - `fixed_manifest_keys.txt`: contents of the `.permissions`, `.host_permissions`, and `.action` keys in `mv3_extension_fixed/manifest.json`. - `verification.json`: ```json { "finding_1_resolved": "<bool>", "finding_2_resolved": "<bool>", "finding_3_resolved": "<bool>", "finding_4_resolved": "<bool>", "popup_renders_after_sw_restart": "<bool>", "errors_panel_clean_after_fix": "<bool>", "fixed_zip_size_bytes": "<int>" } ``` `finding_N_resolved` corresponds one-to-one with the N-th finding in `manifest_audit.json`; the booleans must come from real collection and must not be hard-coded. - `mv3_postmortem.md`: ≥300 characters, containing: - one paragraph for each of the 4 findings (aligned with the ids in `manifest_audit.json`); - why MV3 cannot keep state in module-scope variables in the background like MV2 did (reference SW lifecycle: idle → terminated → restarted on event); - why fixing the missing popup must be done in the manifest rather than in `background.js`; - the relationship between `host_permissions` and `content_scripts.matches` (why the latter ⊆ the former); - engineering recommendations before shipping (e.g. `web-ext lint` or chrome.webstore validator). Must include keywords "service worker", "lifecycle", and "chrome.storage". - `view_12_combined_proof.png`: a single screenshot showing simultaneously: the fixed extension card with no Errors, the popup open with data in it, and a command line displaying that the `.permissions` of `mv3_extension_fixed/manifest.json` contains `"alarms"` — as cross-channel consistency evidence.

- Chrome MV3 docs: https://developer.chrome.com/docs/extensions/develop/migrate
- MV3 service worker lifecycle: https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle
- chrome.storage API: https://developer.chrome.com/docs/extensions/reference/api/storage
- chrome.alarms API: https://developer.chrome.com/docs/extensions/reference/api/alarms
- 真实 incident: 多个 GitHub MV2→MV3 迁移 issue(如 mozilla/web-ext#2491、google/web-ext-types tracker)以及 Stack Overflow `manifest v3 background state lost`

- 最终交付:对 `mv3_extension/` 完成静态审计、故障复现、修复并提供 `mv3_extension_fixed/` 与对应的可视化证据。
- 系统应能体现:加载 fixed 版本后扩展卡片无 Errors,工具栏图标点击能真实弹出 popup,background SW 自动 terminate 并重启后 popup 仍能展示累计数据。
- 产物中应能验证:`manifest_audit.json` 列出的 ≥4 条 findings 在修复版本里被逐条解决,且 `evidence_path` 与原 manifest 真实存在。
- `verification.json` 中四条 `finding_N_resolved`、`popup_renders_after_sw_restart`、`errors_panel_clean_after_fix` 应真实采集为 true。
- `mv3_postmortem.md` 应说明 MV3 SW 生命周期与状态持久化的关系,并把整套修补串起来。
- 综合证据截图应在同一画面同时呈现扩展管理页面、popup 内容与命令行权限输出,跨通道交叉印证修复结果。

- [ ] 1. `manifest_audit.json` 是合法 JSON,包含 ≥4 条 findings 且每条字段齐
- [ ] 2. `mv3_extension.zip` 存在,`zip_listing.txt` 含 5 个必备文件
- [ ] 3. `view_01_extensions_devmode.png` + `view_02_ext_card_errors.png` 存在,OCR 命中 "Developer mode" 或 "Errors" 或 "service worker"
- [ ] 4. `view_03_popup_fail.png` 存在,OCR 命中 "Reading Time"
- [ ] 5. `view_04_bg_sw_devtools.png` 存在,OCR 命中 "chrome-extension" 或 "Console" 或 "alarms"
- [ ] 6. `view_05_permissions_dump.png` 存在,OCR 命中 "permissions" 或 "tabs"
- [ ] 7. `repro_report.md` ≥220 字 + 引用 ≥3 个 file:line + 含 "service worker" / "lifecycle" / "alarm"
- [ ] 8. `view_06_state_before.png` + `view_07_state_after_restart.png` 存在
- [ ] 9. `mv3_extension_fixed/manifest.json` 修对(声明类违例 ≥ 2 项被消除,grader 用 jq 自动校验)
- [ ] 10. `mv3_extension_fixed/background.js` 实现了状态在 SW 重启之间可恢复(grader 用静态扫 + GUI view_11 联合判定)
- [ ] 11. `fix_diff.patch` 非空且涵盖 manifest + background
- [ ] 12. `view_08_ext_no_errors.png` + `view_09_popup_works.png` + `view_10_popup_with_data.png` + `view_11_state_persisted.png` 存在
- [ ] 13. `verification.json` 字段齐,关键 4 项布尔为 true
- [ ] 14. `mv3_postmortem.md` ≥300 字含 "service worker lifecycle" + "chrome.storage" + 4 个 finding id
- [ ] 15. `view_12_combined_proof.png` 存在
- [ ] 16. VLM 验:DevTools SW console 真截图 + popup 真弹 + Errors panel 真红字 + 修复后状态可持久

评分采用模型判定的标准；本项目未进行评分器运行验证。