You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
utils/jsonl_parser.py::_parse_tool_result classifies Claude Code toolUseResult blobs through a ~140-line if/elif chain across 14 result families (eval §5.1; arms enumerated in Issue #21 Gap 1 table).
Consequences (eval §5.4):
High cognitive load for any contributor reading or modifying tool-result classification.
Schema evolution (new tool, renamed key, new variant of task / web_fetch) requires editing the chain in place — error-prone, merge-conflict-prone.
The “add a tool type” path is not localized.
The tests landed in PR #22 protect existing behavior; this refactor changes structure only, not semantics.
Goal
Replace the pattern-matching chain with an explicit dispatch table / ordered registry of (predicate, handler) (or equivalent), so that:
Each tool/result family is a small named function.
New families are added by one registration line + one handler, not by inserting another elif arm.
Add a short docstring or README-level note showing how to register a new tool family (one place to add).
Scope (out) — explicit
CCC2: GitHub Actions pytest workflow.
CCC3: rewriting other modules’ tests off cross-module _-prefixed imports.
_process_assistant exception strategy — the “no exception handling” phrase in CCC1’s finding text. PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22 verifies no-crash behavior on bad inputs; adding real try/except + safe error surface is a separate follow-up.
Any change to what a tool result classifies as (semantics).
Acceptance criteria
_parse_tool_result is implemented via an explicit dispatch table / registry, not a long if/elif ladder.
Adding a hypothetical new tool family is demonstrably a single primary registration site (verifiable by reading the diff or the new module-level docstring).
pytest green locally.
PR description references this issue, CCC1 (structural prong), eval §5.1 / §5.4, and yesterday’s Issue #21 / PR #22.
Coverage map (CCC1 closure)
CCC1 piece
Closed by
Tests for 14 dispatch arms, helpers, integration, malformed inputs
Issue —
claude-code-chat-browser— Refactor_parse_tool_resultdispatch table (5 pt)Sprint: Wednesday, May 6 — Claude-code Refactor + Exclusion Consolidation (8 pt total; this item = 5 pt, task 1 of 2)
Repo: cppalliance/claude-code-chat-browser
Audit:
claude-cursor.mdCCC1 (structural half) +claude-code-browser-eval.md§5.1 / §5.4. (Both audit docs are internal; not on GitHub.)(After opening on GitHub, paste the issue URL here.)
Background — what CCC1 actually asks for
CCC1’s Fix column in
claude-cursor.mdhas two prongs:jsonl_parser.pycovering schema variants, malformed entries, and exception paths._parse_tool_result’sif/elifchain to a dispatch table so new tool types are a single-site change.Yesterday closed prong (1). This issue closes prong (2).
Problem
utils/jsonl_parser.py::_parse_tool_resultclassifies Claude CodetoolUseResultblobs through a ~140-lineif/elifchain across 14 result families (eval §5.1; arms enumerated in Issue #21 Gap 1 table).Consequences (eval §5.4):
task/web_fetch) requires editing the chain in place — error-prone, merge-conflict-prone.The tests landed in PR #22 protect existing behavior; this refactor changes structure only, not semantics.
Goal
Replace the pattern-matching chain with an explicit dispatch table / ordered registry of
(predicate, handler)(or equivalent), so that:elifarm.Scope (in)
_parse_tool_resultonly inutils/jsonl_parser.py. Internal helpers may be added in the same module if they aid clarity.bash,file_edit,file_write,glob,grep,file_read,web_search,web_fetch, fourtaskvariants,todo_write,user_input,plan,unknownfallback.toolUseResult→Nonebehavior intact (Gap 9 in PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22).README-level note showing how to register a new tool family (one place to add).Scope (out) — explicit
pytestworkflow._-prefixed imports._process_assistantexception strategy — the “no exception handling” phrase in CCC1’s finding text. PR test(jsonl): add jsonl_parser schema coverage and harden null usage #22 verifies no-crash behavior on bad inputs; adding realtry/except+ safe error surface is a separate follow-up.Acceptance criteria
_parse_tool_resultis implemented via an explicit dispatch table / registry, not a longif/elifladder.tests/test_jsonl_parser.py::TestParseToolResult+ integration) pass without modification.pytestgreen locally.Coverage map (CCC1 closure)
_parse_tool_resultif/elif → dispatch table (eval §5.4)_process_assistantexception strategy (CCC1 finding text)pytest_-prefixed parser symbolsAfter this PR ships, the Fix column of CCC1 is satisfied; the residual three rows above remain as separate tickets.