project_artifact_content_quality.md 2.13 KB

name: project-artifact-content-quality description: code_diff/test_report artifacts in this project's self-hosting runs sometimes contain placeholder/wrong text instead of a real diff or report — don't trust artifact content, verify the actual working tree and run tests yourself metadata:

type: project

Observed on task 7400d876-a797-4d87-bcff-4e59a3befba1 (v_graph_console / #/graph, 2026-08-03): the code_diff artifact (.graphlemon/runs/<task_id>/code_diff.patch) contained only the literal text (no diff -- see test_report), and the test_report artifact (.graphlemon/runs/<task_id>/test_report.md) contained an unrelated dispatch/notification message ("Launched the graphlemon Work Node (coder) workflow in the background... I'll notify you when it completes") rather than an actual summary of tests run and their results. The real code changes existed and were correct — verified independently via git diff on the actual target repo, running python3 -m unittest discover -s src (513 passed), running the Coder-left node frontend/test_graph_console_smoke.js (passed), and hitting the live backend with curl — but the artifact files meant to document that work did not reflect it.

Why: this matters because [[feedback-no-js-test-framework]] and the general validator mandate ("developer_claim only, must be independently re-verified") both assume you'll actually re-run things — this is a concrete instance where trusting the artifact content alone would have been actively misleading (it looked like nothing was tested), even though the underlying implementation was solid.

How to apply: always independently git diff/re-run tests against the real target repo rather than reading code_diff.patch/test_report.md at face value — treat a garbage-looking artifact as a prompt to dig into the actual working tree/db state (as done here), not as automatic grounds for FAIL, since the artifact-generation step and the actual code-change step can apparently diverge in this pipeline. If this recurs, it may be worth raising as a Coder/skill_defect root-cause candidate on some future task even when the code itself passes.