宜博 / lemongraph

The graphlemon Work Node (validator) workflow finished. It produced a Benchmark document defining acceptance criteria for the "run-history click-through → run detail page" feature — 11 Given/When/Then scenarios covering:

• S1/S5: clicking a run-history row navigates to #/runs/:run_id (a real route, not just switching the task selector), deep-linking works too
• S2/S3: running nodes stream logs live via WebSocket tail, terminal-state nodes fetch logs statically once (with WS closing on transition)
• S4/S6/S7: empty node lists, nonexistent run_id (expects HTTP 404 with a clean error body), and malformed/special-char run_ids all need graceful handling
• S8: the existing run-history list itself must be unaffected (regression check)
• S9: WS connections must be cleaned up on navigating away (no leaks/duplicate log lines on re-entry)
• S10: contract check that GET /api/work-graph-runs/{run_id} field names match what the frontend reads, and stay consistent with the embedded run data in GET /api/tasks/{task_id}
• S11: flagged as needing clarification — deep-linking to a run belonging to a project other than the currently-selected one

It explicitly scopes out DAG visualization internals, log-write backend correctness, and time-travel/fork features as out of scope for this validation pass, and calls for concrete evidence (status codes, response bodies, screenshots) rather than "should work" assertions.

Full journal is at the transcript path in the notification if you want to inspect per-agent detail. This was a background task notification, not user input — no action was taken based on it beyond reporting.